Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
06217 Debugger Critical (emulator) Always May 20, 2016, 20:14 May 26, 2016, 23:38
Tester Tourniquet View Status Public Platform MAME (Official Binary)
Assigned To Tourniquet Resolution Fixed OS Other
Status [?] Resolved Driver
Version 0.173 Fixed in Version 0.174 Build 64-bit
Summary 06217: Windows debugger crashes on Win10 64-bit
Description Release build of 0.173, as well as bleeding-edge self-compile with latest tools.
Crashes on the Windows debugger.
Imgui debugger is okay.
Steps To Reproduce [MINGW64] C:\Projects\mame>mame64 tnzs -debug
b53-15.pal16l8a.subpcb.ic6.jed NOT FOUND (NO GOOD DUMP KNOWN) (tried in tnzs tnzs)
WARNING: the machine might not run correctly.

Exception at EIP=000000000000BABE (+0xbabe): ACCESS VIOLATION
While attempting to write memory at 000000000000BABE
RAX=0000000000000407 RBX=0000000008A18650 RCX=000000000EC0EE10 RDX=0000000008A18650
RSI=000000000A93D900 RDI=0000000000000000 RBP=0000000008A18620 RSP=0000000008A185E8
 R8=0000000008A185F8 R9=0000000008A18680 R10=0000000000000000 R11=0000000000000246
R12=000000000A9AE540 R13=0000000008A189CC R14=00000000179BE910 R15=0000000008A18BC0
Stack crawl:
  0000000008A185E0: 000000000000BABE (+0xbabe)
  0000000008A18620: 0000000001715FA7 (winwindow_dispatch_message(running_machine&, tagMSG*)+0x0057)
  0000000008A186A0: 00000000016FF91C (debugger_windows::wait_for_debugger(device_t&, bool)+0x019c)
  0000000008A186D0: 00000000016F23D9 (osd_common_t::wait_for_debugger(device_t&, bool)+0x0019)
  0000000008A18980: 0000000002A4A693 (device_debug::instruction_hook(unsigned int)+0x03d3)
  0000000008A18A00: 0000000001F839FE (z80_device::execute_run()+0x01ee)
  0000000008A18AA0: 0000000002A08D6E (device_scheduler::timeslice()+0x01ae)
  0000000008A18B00: 00000000029D3088 (running_machine::run(bool)+0x0138)
  0000000008A1F4F0: 000000000178F2FA (mame_machine_manager::execute()+0x015a)
  0000000008A1F960: 000000000180A9D2 (cli_frontend::execute(int, char**)+0x1092)
  0000000008A1F9D0: 000000000178E555 (emulator_info::start_frontend(emu_options&, osd_interface&, int, char**)+0x0035)
  0000000008A1FDF0: 00000000016F1834 (utf8_main(int, char**)+0x0124)
  0000000008A1FE50: 0000000002E9085F (wmain+0x007f)
  0000000008A1FF20: 000000000040140C (__tmainCRTStartup+0x025c)
  0000000008A1FF50: 000000000040153B (mainCRTStartup+0x001b)
  0000000008A1FF80: 00007FFAB9528102 (BaseThreadInitThunk+0x0022)
  0000000008A1FFD0: 00007FFABB51C5B4 (RtlUserThreadStart+0x0034)
Additional Information
Regression Version 0.173
Affected Sets / Systems
Attached Files
There are no relationship linked to this issue.
User avatar
May 20, 2016, 20:18
Suspicion was this was related to Brad's commit pre-vacation.
User avatar
May 21, 2016, 01:01
This relates to XAudio.
Doesn't crash with -sound dsound as suggested by Tafoid.
User avatar
May 21, 2016, 04:05
unable to reproduce here on my Win10 64-bit rig.

*mame64 tnzs -sound xaudio2 -debug* doesn't crash on my end. Tried 10 or so different random games that use different drivers and am unable to reproduce any crash.
User avatar
May 21, 2016, 21:48
As per message to the list:
"Okay, VS2015 was very helpful.
As per the MinGW/gdb stacktrace, it's a crash in window.cpp handling what it believes is a WM_USER_EXEC_FUNC message (WMUSER+7).
It actually has a message->wParam of 0xBABE, which seems like a common/sentinel value.

I only get these messages when XAudio is enabled, and this code is only reached when -debug is used in conjunction, presumably because the emulation starts paused.

If I comment out the single line that executes wParam as a function pointer, then emulation and the debugger appears to function perfectly.

So the question is - where are these events coming from? I note that the event polling is pass a nullptr to WaitMessage(), which seems to imply that we get all messages for the windows for the thread or other messages with no value set...
I guess there's some crossover from the XAudio events, and that the imgui debugger, not having a Window, is fine."
User avatar
May 22, 2016, 10:12
Committed fix for this for 0.174. Thanks to smf for clarifying.