crash to desktop when configuring inputs

[httpsterio]

Quick summary

cxbx crashes when configuring input devices.

Details

Latest version (4457d11) crashes after opening input configuration and either configuring one of the ports or by exiting the input config.

System Configuration:

• Windows 10 (build 1904.867)
• Ryzen 3700X
• Nvidia GeForce GTX 970

Additional Information (if any):

Event viewer displays an Error in the Application logs.

Faulting application name: cxbx.exe, version: 0.0.0.0, time stamp: 0x618aaf9c
Faulting module name: cxbx.exe, version: 0.0.0.0, time stamp: 0x618aaf9c
Exception code: 0xc000041d
Fault offset: 0x04425bbb
Faulting process id: 0x2acc
Faulting application start time: 0x01d7dcb05d20c65e
Faulting application path: E:\GAMES\Xbox\cxbxr\cxbx.exe
Faulting module path: E:\GAMES\Xbox\cxbxr\cxbx.exe
Report Id: 505b0a1f-e645-4b29-8fc3-8362bf98c8f5
Faulting package full name:
Faulting package-relative application ID:

And the Information event before the crash

Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: cxbx.exe
P2: 0.0.0.0
P3: 618aaf9c
P4: cxbx.exe
P5: 0.0.0.0
P6: 618aaf9c
P7: c0000005
P8: 04425bbb
P9:
P10:

Attached files:

These files may be available here:
\?\C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_cxbx.exe_38e38630c005f771188b3ac5bdd85c41d1e2bbc_1db3656f_9b9290c5-d56c-4765-9dee-c98ca5d9b0dd

Analysis symbol:
Rechecking for solution: 0
Report Id: 933ae29f-9b3f-47e7-911a-a3dc48780df0
Report Status: 4
Hashed bucket:
Cab Guid: 0

The file mentioned above doesn't get created.

[RadWolfie]

Please attach your settings.ini file in order for us to investigate the problem. You can delete RecentXbeFiles history from the file before upload.

[httpsterio]

settings.ini.txt

Added .txt to the filename so that I could upload it to Github.

[RadWolfie]

Hmm... all of your inputs are not assigned base on the file.

Since you are saying it happen either during assign each layout's buttons or on exit input dialog. I am unable to reproduce this issue. Which emulation device and what hardware device you are trying to use?

[httpsterio]

By emulation device and hardware device, are you meaning input devices?

I have attempted selecting all of the options: MS Gamepad Duke, S, Steel battalion etc.
Everytime I hit "Configure" after selecting any, it'll crash. If I don't select any, just open the Input Config and hit the close button, it'll crash.

As for hardware, I would've used an Xbox One controller with the official wireless USB dongle. It reads up as a generic Xinput device by Windows. Xemu can open it up without any config.

I thought at first this might be a permission issue with the settings.ini but there isn't a difference in if I run cxbxr in portable or install the settings in %AppData%.

[ergo720]

I tried to reproduce this issue with the settings file you posted and selecting all the different device types, and I never got a crash either. Either this is a corner case in the input code or it's an issue on your end specific of your system. Can someone else in the community try to reproduce this, preferably with an xbox one wireless controller if possible?

Xemu can open it up without any config.

That's because xemu does not yet support button remapping, but they have plans to do it in the future.

[httpsterio]

I'll try out older versions of cxbxr to see if it's a regression. I did play JSRF successfully on the same Windows 10 install on this same machine roughly 6 months ago.

None of the other menu settings have had issues with crashing, only input. Are there any options in cxbxr I can set via the application that should get written to the ini? I could try to debug if it's a read/write or folder permission error.

[httpsterio]

I tested older builds. Up until CI-f7042be, the older builds were working for me.

I tested the four previous builds and the input menu opens up without issues while the latest and the build before that introduces some breaking bug on my end. I can only see the introduction of libusb so I'd guess there's something with either the included library or the implementation of it that creates a fatal callback exception.

[RadWolfie]

Thank you for confirmation older builds were working for you. It would make sense hardware passthrough pull request #2290 would likely be the cause for your end of the issue.

The only possibilities cause I can think of right now are:

• VID / PID may have a match and / or possibility thinks your controller is on the list.
  • For this, we'll need your VID and PID of your wireless Xbox One controller.
    
    (Expand this field if you're not sure how to get the info.)

    You can find it through Control Panel > Devices and Printers > right-click your controller device > select "properties" from context menu > Hardware tab > select "HID-compliant game controller" > click Properties > Details tab > under "Property"'s dropdown menu, select "Device instance path". Finally, perform hotkey's copy inside Value's field. Then paste it in new post.
• Our commands' communication for obtain information may not be compatiable yet it should anyway.
  • Or there could be another step require before start using specific command.

EDIT: Sorry we haven't asked you before. Without your wireless Xbox One controller connected, are you still receiving the crash as well? Or is it only specifically your wireless Xbox One controller?

[httpsterio]

I've tried both with and without any controller. I removed all of the controllers from the Devices and Printers and everything disconnected and tried with the controller connected as well, no difference.

Xbox One Wireless Controller
HID\VID_045E&PID_02D1&IG_00\8&29DE5ED9&1&0000

USB Input Device
USB\VID_045E&PID_02D1&IG_00\00&00&0000B3FBEA8AED7E

Those two were both grouped under the same game controller in Devices and Printers.

[RadWolfie]

Okay, even without any controller connected; you still have the same issue. Which lead to something else. Download 7z file from official libusb's release page (v1.0.24). Here's the direct download link. Our libusb is currently about a year ahead of development's commits.

Once you have download libusb-1.0.24.7z file, Open it with 7z software and navigate to examples > bin64 > listdevs.exe file. This is the file you need to extract from 7z archived file. Then run it from a terminal to see any results and if it does crash or not. If listdevs.exe do crash, then the issue is from one of your drivers or programs.

Although if listdevs.exe does not crash. I am willing to make a draft pull request for you to test and see if it works. What draft pull request will do is move our libusb submodule back to libusb's release tag commit.

[httpsterio]

Doesn't crash, here's the output.

Just FYI, I'm perfectly content playing on an older build. This has mostly turned into a curious case for me on what's actually happening. As long as this continues to be useful for you guys, I'm willing to test this out. I appreciate all the debugging help I've gotten so far.

[RadWolfie]

Cool, I recently made a draft pull request for you to test after our CI is done building and produce artifact build.

[httpsterio]

I'm still seeing the same issue with https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/actions/runs/1488582716

[RadWolfie]

Can you run listdevs.exe one more time then check in event viewer for any error from it?

[httpsterio]

No events happening after running.

[RadWolfie]

Then we're not sure how it is affecting from your end. The error and address when the crashed occur shows it is origin from ImGui::TabItemEx function. Except we don't have any ImGui calls from within GUI's end. Plus we did add breakpoint to the address which never triggered it upon open input dialog and their configurations.

Currently, we are stumped. Only way to find out the cause is by catch the exception from IDE such as Visual Studio and read the call stack for how it happened in the first place from your end.

[httpsterio]

Alright well I'll clone the repo and install Visual Studio and see what happens :)

[RadWolfie]

In case you're having issue with setup Cxbx-Reloaded from Visual Studio. The following requirement are:
Workloads (tab)

• .NET desktop development (optional, except will need to manual edit CMakeLists.file to force exclude it.)
• Desktop development with C++

Individual components (tab)

• C++ CMake tools for Windows (optional if already have CMake installed on your system)

[ergo720]

The original author did not respond after almost a month, and no other user has ever reported this problem. Assuming this was a user-specific issue, closing this for now. This can be reopened in the future.

[ergo720]

Another user has reported this problem again here, so this is probably a real issue now. However, we can't fix this until we are able to reproduce it.

[asaguda]

I'm not sure how to contribute toward helping anyone else reproduce it, but it happens here too, and similarily, old builds from last year work okay.
If I try to select a device and hit configuration, it takes a second, and then crashes to desktop. Event Viewer is throwing shade at some local .dlls but I'm not savvy enough to know if that actually means anything.

If I select a device and hit configure, it crashes with cxbx.exe as the application, and ntdll.dll as the faulting module in event viewer. Error code is 0xc0000005.
If I don't select a device and I just hit the X to close the window, it crashes with the same application/module, but the error code changes to 0xc000041d.
The ntdll.dll as the faulting module has remained after reinstalling cxbx as well as running sfc /scannow with the DISM stuff before it- It claimed it updated the recovery stuff fine, and that it found corrupted files and repaired them, but it didn't help.

I also tried the listdevs.exe thing linked earlier, and it works fine. As does the newer 1.0.25 version. No errors thrown in Event Viewer.

So I feel like this is just a big '#MeToo' thing, but thought I might as well.

[ergo720]

PR #2375 fixes a freeze of cxbxr caused by libusb. Since this problem is also very likely caused by libusb, there's a chance that it might improve/fix this issue as well. So, affected users should try testing that PR to see if they are still affected by the issue.

[TakkuZakku]

I've been having the same issue with an original Xbox Controller S with a modded USB cable, only happens when it's plugged in. Originally I thought it was caused by XBCD, but I removed that entirely, removed the drivers for the controller, reinserted it, and still had the same issue. No problems with libusb listdevs.exe either:

listdevs.exe 28de:2101 (bus 2, device 13) path: 9.7 2109:8110 (bus 2, device 1) path: 19 1038:1230 (bus 2, device 15) path: 8.1.2 28de:2300 (bus 2, device 10) path: 9.3 8086:a2af (bus 2, device 0) 045e:001c (bus 2, device 8) path: 3.2 174c:3074 (bus 2, device 2) path: 23 1038:1234 (bus 2, device 16) path: 8.1.3 046d:c332 (bus 2, device 4) path: 7 0451:2036 (bus 2, device 9) path: 8.1 1b21:2142 (bus 1, device 0) 264a:3006 (bus 2, device 6) path: 6 28de:2101 (bus 2, device 12) path: 9.6 174c:2074 (bus 2, device 3) path: 3 0d8c:0013 (bus 2, device 11) path: 9.5 2109:2811 (bus 2, device 5) path: 8 045e:0285 (bus 2, device 14) path: 3.2.1 0424:2137 (bus 2, device 7) path: 9

I went and got everything running with Visual Studio, and this is where it's throwing an exception when clicking the Configure button in Input Settings. Let me know if there's any other info you'd like me to share or want me to try.

Edit: I also wanted to mention that if I leave the controller unplugged, open the Input Settings page, then plug it in, it will allow me to open the Configure window and it will display the controller. However, it will still crash after that point when trying to Test the controller or exit out of any of the open windows.

[TakkuZakku]

I've looked into it a little bit more, and I've found that this particular controller is coming back with -12 LIBUSB_ERROR_NOT_SUPPORTED with usbi_backend.open(_dev_handle) in libusb_open. I'm wondering then why m_Type is not marked as DEVICE_INVALID and thus ends up with the interface trying to be released resulting in the read access violation in my previous comment. I'm also wondering why it's getting LIBUSB_ERROR_NOT_SUPPORTED when it tries to open it, as for all I know it should be supported with the USB passthrough. Still hoping someone can help with this, as the only other controller I have kinda sucks and I'd like to use this one. Even though I'm a developer, a lot of this stuff is far from what I'm familiar with. As much as I'd like to figure it out myself, I'm not sure I can!

Edit: the controller is an Xbox Controller S, device id 0x0285

[RadWolfie]

Great research progress so far! 😃
Can you tell us which line is the fault from cxbxr's end? Unfortunately, call stack doesn't help us fully since it stopped at InputDeviceManager::RefreshDevices() then skip over to LibusbDevice's destruction.

[ergo720]

It's because that device id is in the supported list here, which in turn was taken from here. According to the list, this should correspond to a Japanese orginal xbox controller. So either your device has the same id of that controller or the list is incorrect.

EDIT: When I read "Xbox Controller S", I thought it was an xbox one controller, but now I understand the user is referring to an original xbox controller though.

[TakkuZakku]

Great research progress so far! 😃 Can you tell us which line is the fault from cxbxr's end? Unfortunately, call stack doesn't help us fully since it stopped at InputDeviceManager::RefreshDevices() then skip over to LibusbDevice's destruction.

Not sure I understand the question, but I'll try. It was trying to clear m_Devices (line 780 in InputManager.cpp), then it ended up in the destructor for the libusb device. When debugging I can't get passed the unhandled exception, I assume that's where cxbx is closing, but I'm not that familiar with C++ so I don't really know what happens after unhandled exceptions.

It's because that device id is in the supported list here, which in turn was taken from here. According to the list, this should correspond to a Japanese orginal xbox controller. So either your device has the same id of that controller or the list is incorrect.

EDIT: When I read "Xbox Controller S", I thought it was an xbox one controller, but now I understand the user is referring to an original xbox controller though.

Yes, it is an original Xbox Controller S, although nothing on the outside of it tells me that it's a Japanese one. It certainly doesn't resemble the grey with green logo one I see online called the "Japanese" Controller S. Wonder if that has anything to do with it.

[RadWolfie]

Okay, it clearly populate devices when open up input config window. Then populate devices again for port # configure. It's clear that LibusbDevice.cpp at line 190 for attempt to open device through libusb_open call you mentioned return as an error. You are right for missing DEVICE_INVALID set to m_Type and a return. For rough translation into C++ code is:

		// check if we are able to open device through libusb
		if (int err = libusb_open(Dev, &m_hDev) != 0) {
			// Couldn't open device, create an error log report then don't use it.
			EmuLog(LOG_LEVEL::ERROR2, "Unable to open original xbox device \"%s\" (%hX:%hX), libusb's error was: %s",
				m_Name.c_str(), Desc->idVendor, Desc->idProduct, libusb_strerror(err));
			m_Type = XBOX_INPUT_DEVICE::DEVICE_INVALID;
			return;
		}
		// If we are able to open device, continue with query process.
		else {
			// Duke, S and SBC have 1 configuration, 1 interface and 2 endpoints (input and output) and use the default alternate setting zero.
			// The code below assumes that third-party controllers follow suit.

Above code will avoid unintentional crash, yet will cause lose support for it.

It is unclear if we did something wrong on our end or an issue between the device and computer.

---

EDIT:
I took a look into libusb's listdevs example codebase. It obviously doesn't use libusb_open call which is why it show as working. Different example or troubleshooter is needed to verify if the controllers are functional or not.

[RadWolfie]

We think LIBUSB_ERROR_NOT_SUPPORTED error you received from libusb_open call is due to missing WinUSB compliant driver for your Xbox Controller S device. Can you verify this please?

@ergo720 gave me the link for libusb's suggestive software to use for install WinUSB driver. If haven't installed WinUSB driver for og xbox devices.

[RadWolfie]

I found the OP, @httpsterio, and @TakkuZakku's latter issue for the crash. According to this line

Cxbx-Reloaded/src/common/input/LibusbDevice.cpp

Line 173 in 547c3ae

if ((Desc->idVendor = SupportedDevices_VidPid[i][0]) && (Desc->idProduct == SupportedDevices_VidPid[i][1])) {

end-user's vendor id is getting overriden by using assignment instead of comparison operator. I notice their product ids do indeed match on SupportedDevices_VidPid's pid list and cause the crash because of their devices could not be opened which didn't cover the error check.

I have prepared a branch to resolve two separate issues on this ticket.