Project

General

Profile

Emulator Issues #11511

Consistent Crashing with Rock Band (2008)

Added by InlineData 10 months ago. Updated 5 months ago.

Status:
Fixed
Priority:
Normal
Assignee:
% Done:

0%

Operating system:
Windows
Issue type:
Bug
Milestone:
Regression:
Yes
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:
5.0-10344

Description

Game Name?

Rock Band

Game ID? (right click the game in the game list, properties, info tab)

RKXE69

MD5 Hash? (right click the game in the game list, properties, info tab, MD5 Hash: Compute)

9237fa2eb595945bca61d58d0869bcb2

What's the problem? Describe what went wrong.

Frequent crashes when trying to USB passthrough a Rock Band 2 guitar for Rock Band. This is normally possible on the WII version of Rock Band since the Rock Band 2 guitars were reverse compatible.

What steps will reproduce the problem?

Go under Config->Wii->Whitelisted USB Passthrough Devices->Add... and add 1:bad:3010 Afterward play Rock Band. Dolphin will crash a short amount of time after starting but at no fixed point in time.

Hardware Used:

Dongle Info: Model #WGTSELEA2B
Device: Harmonix Guitar Controller for Nintendo Wii VID: 1BAD PID: 3010

Guitar Info: Model #NWGTS2

Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.

5.0-9277

Is the issue present in the latest stable version?

No 5.0 is fine. I was able to use that specified guitar as normal.

If the issue isn't present in the latest stable version, which is the first broken version? (You can find the first broken version by bisecting. Windows users can use the tool https://forums.dolphin-emu.org/Thread-green-notice-development-thread-unofficial-dolphin-bisection-tool-for-finding-broken-builds and anyone who is building Dolphin on their own can use git bisect.)

Sorry I didn't have the time to find the version between the two that breaks Dolphin.

If your issue is a graphical issue, please attach screenshots and record a three frame fifolog of the issue if possible. Screenshots showing what it is supposed to look like from either console or older builds of Dolphin will help too. For more information on how to use the fifoplayer, please check here: https://wiki.dolphin-emu.org/index.php?title=FifoPlayer

Not graphical

What are your PC specifications? (CPU, GPU, Operating System, more)

Intel i7-4770
RAM 16GB
NVIDIA GTX 670
nvidia-driver 384-94
Windows 10 Pro

Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)

See attached

Screenshot (3404).png (139 KB) Screenshot (3404).png InlineData, 01/02/2019 04:00 AM
Screenshot (3717).png (205 KB) Screenshot (3717).png InlineData, 01/10/2019 07:17 AM
Screenshot (3951).png (185 KB) Screenshot (3951).png InlineData, 01/18/2019 07:31 AM
7166
7178
7190

History

#1 Updated by JMC4789 10 months ago

  • Assignee set to leoetlino

Are you using libUSB (WinUSB driver) or usbdk. This isn't a regression in Dolphin exactly as it won't happen in Linux under good libUSB support.

You can try installing different drivers to see if one works better. You can also try using a faster USB port. This is a shitty situation as there isn't much we can do about it iirc.

#2 Updated by leoetlino 10 months ago

  • Regression changed from No to Yes
  • Operating system Windows added
  • Operating system deleted (N/A)

Any chance you could load the debugging info so we can see where it's crashing?

I think we should still consider this a regression as it used to work fine in 5.0.

#3 Updated by InlineData 10 months ago

JMC4789 wrote:

Are you using libUSB (WinUSB driver) or usbdk. This isn't a regression in Dolphin exactly as it won't happen in Linux under good libUSB support.

You can try installing different drivers to see if one works better. You can also try using a faster USB port. This is a shitty situation as there isn't much we can do about it iirc.

I was using libusbk for the driver following the instructions posted here for dolphin 5.0-2352 and newer: https://wiki.dolphin-emu.org/index.php?title=USB_Passthrough I replaced the driver with Zadig. I will try to use a different driver and different usb ports and see if the results change and post updates when I get the chance.

#4 Updated by JMC4789 10 months ago

Please do... it's one of those things where it may be out of our control, unfortunately.

#5 Updated by InlineData 10 months ago

leoetlino wrote:

Any chance you could load the debugging info so we can see where it's crashing?

I think we should still consider this a regression as it used to work fine in 5.0.

Sorry, I'm new to this project and just haven't quite gotten there yet. I will try to post again where it crashes after I figure out adding debugging symbols and I get a chance. Thank you for your attention on this matter.

#6 Updated by markwest76 9 months ago

I think this is the same problem that affects usb Passthrough in "We Sing" and "We Sing Robbie Williams" (instead "We Sing 80s" works perfectly, maybe because it has a more recent game engine?)...the problem is that Dolphin self-closes itself at random times without an error notice or pop-up, so in such case is there a way to have an error log registered anywhere?

#7 Updated by JMC4789 9 months ago

Try using Linux, it shouldn't crash there. I'm not saying that sarcastically, it'd be nice to know for sure this is the libUSB shenanigans.

#8 Updated by markwest76 9 months ago

Easier said than done: other than installing a new OP, there's not even an automatic buildbot for linux...

#9 Updated by JMC4789 9 months ago

I mean building Dolphin on modern linux is pretty easy, evne I can do it when I'm not lazy.

Also, I'm not expecting you to do it, I know this happens. It just depends on how Windows + LibUSB is feeling on a particular computer as to how well it works. It happened to me for years, then stopped happening, and is happening again now. I'll reinstall the drivers a couple dozen times and it'll start working again for a while. It's not a bug in Dolphin as far as I can tell, but, we probably shouldn't crash.

#10 Updated by markwest76 9 months ago

What's strange is that not every game is affected: on my system it seems that the old We Sing series (We Sing and We Sing RW) crash (self-close) randomly, while newest Wii Sing series (like We Sing 80s) and Let's Sing series don't crash...why is that happening? I mean if there's a bug in the Windows or UsbDk or Libusb driver, why only some game crash and the other don't?

#11 Updated by InlineData 9 months ago

InlineData wrote:

JMC4789 wrote:

Are you using libUSB (WinUSB driver) or usbdk. This isn't a regression in Dolphin exactly as it won't happen in Linux under good libUSB support.

You can try installing different drivers to see if one works better. You can also try using a faster USB port. This is a shitty situation as there isn't much we can do about it iirc.

I was using libusbk for the driver following the instructions posted here for dolphin 5.0-2352 and newer: https://wiki.dolphin-emu.org/index.php?title=USB_Passthrough I replaced the driver with Zadig. I will try to use a different driver and different usb ports and see if the results change and post updates when I get the chance.

I replaced the driver with the original default driver that was installed when the dongle was first plugged in (hidusb) and the crashing stopped. Thank you for the suggestion. I guess that it is a support issue you usbdk on windows 10. Also because this seemed to fix the issue I will not continue with other peoples suggestion thank you everyone though!

Side note in my testing I found that the microphone would not work under any driver including its default usbaudio. This includes winusb usbdk usbwin32 (I was trying everything zadig had just out of curiosity). After a couple minutes of play there would be a crash on any of these usb drivers. The setup should have been correct too usb passthrough and whatnot. I will probably make a new issue thread when I get the chance once again unless advised otherwise.

#12 Updated by JMC4789 9 months ago

Like I said, more issues probably won't help. This is an issue beyond what anyone in Dolphin can fix. LibUSB support just sucks in Windows compared to Linux.

#13 Updated by markwest76 9 months ago

Well I don't think it really sucks so much, in fact a lot of games work very good and the only ones that I found not working for now are the old We Sings and the culprit must be the fact that they were designed to work only with the Logitech microphone, while newer We Sings editions (like We Sing 80s) are compatible with every usb microphone. So in this cases there must be some conflict with the exclusive Logitech usb code and I also wouldn't be 100% sure that Linux could fix that problem...

#14 Updated by InlineData 9 months ago

markwest76 wrote:

Well I don't think it really sucks so much, in fact a lot of games work very good and the only ones that I found not working for now are the old We Sings and the culprit must be the fact that they were designed to work only with the Logitech microphone, while newer We Sings editions (like We Sing 80s) are compatible with every usb microphone. So in this cases there must be some conflict with the exclusive Logitech usb code and I also wouldn't be 100% sure that Linux could fix that problem...

I agree. Coverage seems to be pretty good. This is pretty much the only game I had trouble with personally. It would be nice if I could get it to work though without having to install Linux.

Side note: the USB Microphone I'm using is an original Rock Band microphone (Model Number: A-0234A VID: 046D PID: 0A03) so unfortunately I think that isn't the issue. I was going to do a build of Dolphin on Windows that way I could have debugging symbols to see where it crashes. I will post them later if anyone is interested. Sorry it took so long been busy.

#15 Updated by JMC4789 9 months ago

I actually know why it fails on Windows... the USB Microphones (and camera) use a feature that isn't well supported. I forget what it's called, but, Microphones and Camera only consistently work on Linux.

#16 Updated by InlineData 9 months ago

7178

InlineData wrote:

markwest76 wrote:

Well I don't think it really sucks so much, in fact a lot of games work very good and the only ones that I found not working for now are the old We Sings and the culprit must be the fact that they were designed to work only with the Logitech microphone, while newer We Sings editions (like We Sing 80s) are compatible with every usb microphone. So in this cases there must be some conflict with the exclusive Logitech usb code and I also wouldn't be 100% sure that Linux could fix that problem...

I agree. Coverage seems to be pretty good. This is pretty much the only game I had trouble with personally. It would be nice if I could get it to work though without having to install Linux.

Side note: the USB Microphone I'm using is an original Rock Band microphone (Model Number: A-0234A VID: 046D PID: 0A03) so unfortunately I think that isn't the issue. I was going to do a build of Dolphin on Windows that way I could have debugging symbols to see where it crashes. I will post them later if anyone is interested. Sorry it took so long been busy.

For those that might be interested in a more helpful screenshot with debugging symbols please see the attached screenshot. This crash occurred with me using the usb microphone I described earlier approximately 8 mins into gameplay. I don't know if it is something that could be fixed. It does seem to be something related to libusb as suspected.

I'm not too familiar with libusb or the design of dolphin's emulator being really new here but if I may pose a possibly really dumb question: could this exception be handled? I'm imagining this problem is related to dolphin polling on data that isn't ready because of issues on libusb's end. Assuming that libusb eventually gets back on track (polling data) could we catch this exception send a temporary value to the emulator while the data isn't present from libusb and then resume once libusb has caught up. This would most definitely probably be a kludge but might be the only thing that could be done without libusb being fixed. I don't think the libusb team would fix it because it seems like most the work on those projects stopped 2 years ago. Sorry I though I would just pose this question just in case it was productive. If it is really really dumb you don't have to dignify it with an answer XD

#17 Updated by InlineData 9 months ago

InlineData wrote:

InlineData wrote:

markwest76 wrote:

Well I don't think it really sucks so much, in fact a lot of games work very good and the only ones that I found not working for now are the old We Sings and the culprit must be the fact that they were designed to work only with the Logitech microphone, while newer We Sings editions (like We Sing 80s) are compatible with every usb microphone. So in this cases there must be some conflict with the exclusive Logitech usb code and I also wouldn't be 100% sure that Linux could fix that problem...

I agree. Coverage seems to be pretty good. This is pretty much the only game I had trouble with personally. It would be nice if I could get it to work though without having to install Linux.

Side note: the USB Microphone I'm using is an original Rock Band microphone (Model Number: A-0234A VID: 046D PID: 0A03) so unfortunately I think that isn't the issue. I was going to do a build of Dolphin on Windows that way I could have debugging symbols to see where it crashes. I will post them later if anyone is interested. Sorry it took so long been busy.

For those that might be interested in a more helpful screenshot with debugging symbols please see the attached screenshot. This crash occurred with me using the usb microphone I described earlier approximately 8 mins into gameplay. I don't know if it is something that could be fixed. It does seem to be something related to libusb as suspected.

I'm not too familiar with libusb or the design of dolphin's emulator being really new here but if I may pose a possibly really dumb question: could this exception be handled? I'm imagining this problem is related to dolphin polling on data that isn't ready because of issues on libusb's end. Assuming that libusb eventually gets back on track (polling data) could we catch this exception send a temporary value to the emulator while the data isn't present from libusb and then resume once libusb has caught up. This would most definitely probably be a kludge but might be the only thing that could be done without libusb being fixed. I don't think the libusb team would fix it because it seems like most the work on those projects stopped 2 years ago. Sorry I though I would just pose this question just in case it was productive. If it is really really dumb you don't have to dignify it with an answer XD

Sorry just catching myself with a mistake: when I meant catching the exception I mean check if the list->next was null and doing something appropriate to handle that case

#18 Updated by leoetlino 9 months ago

JMC4789 wrote:

I actually know why it fails on Windows... the USB Microphones (and camera) use a feature that isn't well supported. I forget what it's called, but, Microphones and Camera only consistently work on Linux.

Isochronous transfers. They seem to cause a lot of trouble in libusb on Windows.

InlineData wrote:

Sorry just catching myself with a mistake: when I meant catching the exception I mean check if the list->next was null and doing something appropriate to handle that case

That's not possible. If you look carefully, you'll notice that this is entirely in libusb code. It's crashing in libusb code. Of course, it's still possible that Dolphin is using libusb wrong, but this has all the signs of being a problem in libusb especially when you consider that the same code works without any issues on Linux and also on Windows as long as isochronous transfers are not involved.

Could you also show the stacktrace, so we can see what it was doing right before the crash?

#19 Updated by markwest76 9 months ago

I wanted to report that as I said microphone work perfectly on Windows 10 with every Let's Sing game and every We Sing game except We Sing and We Sing Robbie Williams that are the only ones that support only Logitech microphone, so according to your words in those two games isochronous transfers should be used while in every other game not…

Could you tell me how to get a stacktrace when Dolphin self-closes itself without any error messages?

#20 Updated by leoetlino 9 months ago

Well, all microphone and Wii Speak titles use isochronous transfers, but there are several different interfaces and the games themselves may be setting up transfers differently. It's hard to tell what the issue is without a stack trace, but I'd bet it's related in some way to isochronous transfers considering we've had so many issues with them.

You need to launch Dolphin in a debugger (since you're on Windows, use Visual Studio).

#21 Updated by markwest76 9 months ago

Sorry, I'm not a real Visual Studio expert (in fact I've never used it until today :-/), so what option/path do I have to choose in Visual Studio to launch Dolphin?

#22 Updated by JosJuice 9 months ago

Open the Source/dolphin-emu.sln that is in the Dolphin git repo, then press the Local Windows Debugger button (with a green play icon) in the toolbar at the top of the screen. For performance reasons, you may want to change from debug build to release build before you press Local Windows Debugger, which can be done in the same toolbar.

#23 Updated by InlineData 9 months ago

7190

leoetlino wrote:

JMC4789 wrote:

I actually know why it fails on Windows... the USB Microphones (and camera) use a feature that isn't well supported. I forget what it's called, but, Microphones and Camera only consistently work on Linux.

Isochronous transfers. They seem to cause a lot of trouble in libusb on Windows.

InlineData wrote:

Sorry just catching myself with a mistake: when I meant catching the exception I mean check if the list->next was null and doing something appropriate to handle that case

That's not possible. If you look carefully, you'll notice that this is entirely in libusb code. It's crashing in libusb code. Of course, it's still possible that Dolphin is using libusb wrong, but this has all the signs of being a problem in libusb especially when you consider that the same code works without any issues on Linux and also on Windows as long as isochronous transfers are not involved.

Could you also show the stacktrace, so we can see what it was doing right before the crash?

Oh sorry my mistake. I thought it might be an interface to the libusb code that we wrote and therefore we could have some control in fixing it.

As for the stacktrace here is a stacktrace right before the crash in text:

[Inline Frame] Dolphin.exe!list_del(list_head *) Line 137   C
[Inline Frame] Dolphin.exe!usbi_disconnect_device(libusb_device *) Line 749 C
Dolphin.exe!libusb_unref_device(libusb_device * dev) Line 1189  C

Dolphin.exe!IOS::HLE::Device::USBHost::AddNewDevices(std::set,std::allocator > & new_devices, std::mapstd::shared_ptr<IOS::HLE::USB::Device,enum IOS::HLE::Device::USBHost::ChangeEvent,std::lessstd::shared_ptr<IOS::HLE::USB::Device >,std::allocatorstd::pair<std::shared_ptr<IOS::HLE::USB::Device const ,enum IOS::HLE::Device::USBHost::ChangeEvent> > > & hooks, bool always_add_hooks) Line 150 C++
Dolphin.exe!IOS::HLE::Device::USBHost::UpdateDevices(bool always_add_hooks) Line 116 C++
Dolphin.exe!IOS::HLE::Device::USBHost::Open(const IOS::HLE::OpenRequest & request) Line 50 C++
Dolphin.exe!IOS::HLE::Device::OH0::Open(const IOS::HLE::OpenRequest & request) Line 39 C++
Dolphin.exe!IOS::HLE::Kernel::OpenDevice(IOS::HLE::OpenRequest & request) Line 507 C++
Dolphin.exe!IOS::HLE::Kernel::HandleIPCCommand(const IOS::HLE::Request & request) Line 523 C++
[Inline Frame] Dolphin.exe!IOS::HLE::Kernel::ExecuteIPCCommand(unsigned int) Line 574 C++
Dolphin.exe!IOS::HLE::Kernel::UpdateIPC() Line 639 C++
Dolphin.exe!CoreTiming::Advance() Line 327 C++
[External Code]

And I have a screenshot I will attach for good measure. I hope this what you would like. Thanks again for your attention on this matter!

#24 Updated by markwest76 9 months ago

JosJuice wrote:

Open the Source/dolphin-emu.sln that is in the Dolphin git repo, then press the Local Windows Debugger button (with a green play icon) in the toolbar at the top of the screen. For performance reasons, you may want to change from debug build to release build before you press Local Windows Debugger, which can be done in the same toolbar.

Don't know if it's still necessary, anyway I've tried as you wrote and got following errors:

Error MSB3073 ""%windir%\Sysnative\cscript" /nologo /E:JScript "make_scmrev.h.js"
:VCEnd" con codice 1. SCMRevGen C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets 128

Errore C1083 'Common/scmrev.h': No such file or directory
#include "Common/scmrev.h"
^ Common d:\emulatori\gamecube-wii\dolphin-master-source\dolphin-master\source\core\common\version.cpp 9

Error C1083 'Common/scmrev.h': No such file or directory
#include "Common/scmrev.h"
^ Core d:\emulatori\gamecube-wii\dolphin-master-source\dolphin-master\source\core\core\configmanager.cpp 26

Error C1083 'Common/scmrev.h': No such file or directory
#include "Common/scmrev.h"
^ UICommon d:\emulatori\gamecube-wii\dolphin-master-source\dolphin-master\source\core\uicommon\autoupdate.cpp 15

Error QTDIR not set or non-existent (pull the submodule?) Dolphin D:\Emulatori\Gamecube-Wii\Dolphin-master-source\dolphin-master\Source\VSProps\QtCompile.props 68

#25 Updated by JMC4789 6 months ago

I know it's been a while, but would you like to try some changes? We fixed some USB bugs, both on Dolphin's end and libUSB's end.

For this, you must NOT use usbdk, instead, use zadig to install libusbK (which has working isochronous transfer for the most part,) for the microphone and anything else you think may be crashing.

Then use this build (which will likely not support usbdk anymore) - https://dl.dolphin-emu.org/prs/pr-8070-dolphin-latest-x64.7z

It fixes microphone crashes in Glee, Your Shape, American Idol Encore, and others on Windows for me.

#26 Updated by leoetlino 5 months ago

  • Status changed from New to Fix pending

#27 Updated by markwest76 5 months ago

Thanks, for me PR8070 fixes the problem

#28 Updated by InlineData 5 months ago

I tried to get PR8070 working. I used Zadig 2.4 to install libusbK (v3.0.7.0) onto the Logitech USB Microphone 046d:0a03. Then I tried to run Rock Band. Unfortunately, no microphone was recognized. Are there any other special steps to get this to run? I also tried to add it to the Whitelisted USB Devices under the Wii tab in settings. usbdk isn't currently installed on this system. This is a Windows 7 machine. I can't uninstall usbdk on my main Windows 10 machine without blue screening lol.

#29 Updated by JMC4789 5 months ago

You need to show all devices (I think it's parent/composite) and replace the driver on the composite device.

#30 Updated by markwest76 5 months ago

Now that PR8109 has been merged, I think this issue can be closed...

#31 Updated by leoetlino 5 months ago

I'd prefer keeping this open until PR 8070 is merged, as that PR is still required to fix some libusb crashes on Windows.

#32 Updated by InlineData 5 months ago

@JMC4789 thanks for the advice. The switching the driver on the composite device fixed it.

I tested for 2 songs in Rock Band on vocals with PR 8070 and it worked flawlessly. Thank you to all of the people that worked on this! :D

#34 Updated by leoetlino 5 months ago

  • Fixed in set to 5.0-10344
  • Status changed from Fix pending to Fixed

(sorry, Redmine dropped some of my changes)

Also available in: Atom PDF