New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debugger crash when symbols are present #323

Closed
wk-952 opened this Issue Jun 21, 2015 · 20 comments

Comments

Projects
None yet
4 participants
@wk-952

wk-952 commented Jun 21, 2015

To reproduce this:
*) Make sure you have all symbols downloaded first (i'm not sure which one causes this issue).
1- Load any application in the debugger
2- Restart the application being debugged 18 times
3- On restart attempt number 19, the debugger will crash

  • Information thrown after crash:

Problem signature:
Problem Event Name: BEX
Application Name: x32dbg.exe
Application Version: 0.0.2.5
Application Timestamp: 558646fd
Fault Module Name: MSVCR120.dll
Fault Module Version: 12.0.21005.1
Fault Module Timestamp: 524f7ce6
Exception Offset: 000a7666
Exception Code: c0000409
Exception Data: 00000007
OS Version: 6.3.9600.2.0.0.256.4


  • This issue is introduced since commit da6b666 ,
    building the project with any previous commit seems fine.
  • When pressing "Debug this application" (while x64dbg is set as the JIT debugger),
    x64dbg is loaded up to debug itself but it immediately says "debugging stopped!".
  • It doesn't happen when the symbols folder is not present.
  • If ScyllaHide plugin is installed, the plugin issue from here #303 (plugin file couldn't be loaded)
    will occur at restart number 18.
  • Latest snapshot at sourceforge (snapshot_2015-06-20_02-39) also has this issue.
  • This issue was reproduced after building the project with the latest commit 9cc5949 .
@wk-952

This comment has been minimized.

wk-952 commented Jun 21, 2015

Call Stack table, got it by luck:
http://rghost.net/private/6QVHCSk9P/d0c15be5fba914ac4679cd578ed5e3f4

Here is also a screenshot of the disassembly window from the JIT debugger x64dbg:
err

@mrexodia

This comment has been minimized.

Member

mrexodia commented Jun 21, 2015

Amazing! I also encountered this crash. It might be the memory map. Didn't
expect that.

On Sun, 21 Jun 2015 20:58 wk notifications@github.com wrote:

Call Stack table, got it by luck:
http://rghost.net/private/6QVHCSk9P/d0c15be5fba914ac4679cd578ed5e3f4

Here is also a screenshot of the disassembly window from the JIT debugger
x64dbg:
[image: err]
https://cloud.githubusercontent.com/assets/11916365/8272909/885841f6-1856-11e5-9eee-d59c44873b52.jpg


Reply to this email directly or view it on GitHub
#323 (comment).

mrexodia added a commit that referenced this issue Jun 21, 2015

@wk-952

This comment has been minimized.

wk-952 commented Jun 22, 2015

still the same :(

@wk-952

This comment has been minimized.

wk-952 commented Jun 22, 2015

ok, i found an easy way to debug x64dbg (why didn't i think of this earlier!)
i opened x64dbg and loaded up a game with it (let's call it game debugger),
then i opened another instance of x64dbg and attached the game debugger (JIT debugger).

After that everything was easy, at restart 18 exactly, the game debugger broke and the JIT debugger
reported an access violation error, now it was easy to copy the call stack table, so here it is:
http://rghost.net/private/7GdmZDrYT/bdb2ccc530fa9237922c6744fb210dc5

and also a screenshot of the disassembly window from the JIT debugger at crash:
222_err

@bughoho

This comment has been minimized.

bughoho commented Jun 22, 2015

I found a similar problem.If you press the restart button quickly,All the buttons are invalid.

@mrexodia

This comment has been minimized.

Member

mrexodia commented Jul 13, 2015

I think is issue is resolved now.

@mrexodia mrexodia closed this Jul 13, 2015

@wk-952

This comment has been minimized.

wk-952 commented Jul 13, 2015

It now happens at restart number 74,
also now it doesn't only crash, but also the debugging data gets lost,
and as mentioned in the first post, the files of ScyllaHide plugin could not be loaded,
so the same effects as in issue #303.

For your convenience i removed the symbols folder and tried again, and i was able to restart the application 84 times with no problems,
then i restored the symbols folder and manually compiled the project after adding line # 726 from this commit da6b666 , and this time i reached restart # 100 with no errors or crashes while the symbols are present.

@mrexodia

This comment has been minimized.

Member

mrexodia commented Jul 14, 2015

Hey,

Today I restarted about 200 times. Couldn't reproduce it unfortunately... Does it crash at the same number of restarts for you every time? And is the callstack still the same? Nukem added a crashdump thing in one of the latest commits. Could you try to reproduce do we get a crashdump?

I also fixed various crashes, so it might be solved.

@mrexodia mrexodia reopened this Jul 14, 2015

@wk-952

This comment has been minimized.

wk-952 commented Jul 14, 2015

not exactly, but it's around this range [73, 76] so for me it's not hard to reproduce,
i'll re-compile the project again with those latest 8 commits (the ones done about 3 hours ago)
then if it happened again i'll upload the callstack and the information thrown after crash if it's different.

About the new crashdump feature, could you please tell me how should i do it ? so i can upload it as well with the callstack

EDIT: and by the way thank you and Nukem and everyone involved for this amazing project

@mrexodia

This comment has been minimized.

Member

mrexodia commented Jul 14, 2015

Just get the latest master. The crashdumps are created in a folder called
'minidump'. Just upload anything you get in there.

On Tue, 14 Jul 2015 03:51 wk notifications@github.com wrote:

not exactly, but it's around this range [73, 76] so for me it's not hard
to reproduce,
i'll re-compile the project again with those latest 8 commits (the ones
done about 3 hours ago)
then if it happened again i'll upload the callstack and the information
thrown after crash if it's different.

About the new crashdump feature, could you please tell me how should i do
it ? so i can upload it as well with the callstack


Reply to this email directly or view it on GitHub
#323 (comment).

@wk-952

This comment has been minimized.

wk-952 commented Jul 14, 2015

Okay, here is what happened in the past 2 hours:

  • First it's worth mentioning that now after crashing, no debugging data is lost.

-Attempt 1:
After 73 -74 restarts i got the error: "MiniDumpWriteDump failed. Error: 2147942408"
had to press ok about 6 times or more for that error.
When the debugger crashed it didn't give me the chance to debug it (no "Debug this application" option), but the minidump folder wasn't empty! so i included that in the archive.
EDIT: also in this attempt things got a little bit funky (pictures included in the archive).

-Attempt 2:
Exactly as attempt 1, but this time after crash i had the option to debug the application (x64dbg),
and wonder what happened when i pressed "Debug this application" ....
as mentioned in the first post: " x64dbg is loaded up to debug itself but it immediately says 'debugging stopped!' ", and again the minidump folder had some files in it (although "MiniDumpWriteDump" error occurred again).

-Attempt 3:
This is the interesting one, i did what i mentioned in the 5th post to be able to catch the error when it happens so i can dump the callstack since this was the only way i could do it.
There was a problem here first:
1- open the JIT debugger and the game debugger.
2- attach the game debugger to the JIT debugger.
3- load any game/app in the game debugger.
4- you immediately get a dumping error: "Failed to open file path 'xxx' while generating crash dump" (where 'xxx' is the full path to the dump file).
I guess because the JIT and the game debuggers (who's in fact x64dbg opened twice from the same location) are trying to access the same dump file, so i copied x64dbg (game dbg) to another location, this time when i reproduced the issue and the error occurred, the JIT dbg broke/paused and i could copy the stackcall table.

  • Between each attempt i removed the minidump folder to make sure it's a clean try with its own dumps.
  • In the last attempt the JIT dbg didn't give the "MiniDumpWriteDump" error, but the game dbg did.
  • OS: Windows 8.1 Enterprise 64-bit.

http://rghost.net/private/7pTnsthrC/e2d97320247ea6b5de1bfb702f987cdd
password: asd123

@Nukem9

This comment has been minimized.

Member

Nukem9 commented Jul 14, 2015

Thanks for the info!

2147942408 translates to 0x80070008 - not enough storage is available to process this command. I don't know the exact reason for this right now.

One question (if you have time): if you open crashdump.cpp and go to this line in your own repository, do they match? Based on the generated .dmp files it should be impossible for them to even exist.

@wk-952

This comment has been minimized.

wk-952 commented Jul 14, 2015

I don't clone to my repository, i always download the master branch as a zip file
here's what i see in the crashdump.cpp.
I'll upload later today all the symbols i have along with the build i recompiled.
untitled2

@Nukem9

This comment has been minimized.

Member

Nukem9 commented Jul 14, 2015

Yeah that was what I worried about. != should be == .....this is fixed in the newest commits.

@wk-952

This comment has been minimized.

wk-952 commented Jul 14, 2015

oh crap!, ok no problem i'll do attempt 3 again (very sorry)

@wk-952

This comment has been minimized.

wk-952 commented Jul 14, 2015

It's even worse, i didn't find any dump files in the JIT dbg, and the dump files in the game dbg were 0 byte files!, but anyway here is the callstack again with pics at crash time and at DumpWrite error:

http://rghost.net/private/86VmCdQgh/40091aa4c335b0a422f2bd4bd30159f1
password: asd123

Those are the symbols for x32 that i use:
http://rghost.net/private/6S8RRL4L4/3440b5807168148b13236099c8c7fba0

@Nukem9

This comment has been minimized.

Member

Nukem9 commented Jul 14, 2015

Thanks. There's a Windows bug with the 0-byte dmp files I guess. Nothing I can do.

However, I managed to reproduce an exception myself (it takes around 500 restarts)

0:004> kb
ChildEBP RetAddr  Args to Child              
00d3bdd0 750f43a1 00000000 00000000 00000000 USER32!NtUserWaitMessage+0xc
00d3be18 750e4fcd 00000000 00000000 00000000 USER32!DialogBox2+0x13f
00d3be48 750ef907 00000000 750ee3f0 00d3c090 USER32!InternalDialogBox+0x107
00d3bf14 750ef06d 00d3c090 5517f630 00000000 USER32!SoftModalMessageBox+0xe2c
00d3c078 7513781b 5517f630 25649f20 00000000 USER32!MessageBoxWorker+0x293
00d3c0fc 7513777b 00000000 5517f630 25649f20 USER32!MessageBoxTimeoutW+0x6b
00d3c130 751375bb 00000000 00d3c184 011c2168 USER32!MessageBoxTimeoutA+0x7b
00d3c150 75137588 00000000 00d3c184 011c2168 USER32!MessageBoxExA+0x1b
00d3c16c 011c1207 00000000 00d3c184 011c2168 USER32!MessageBoxA+0x18
00d3c588 011c11a5 011c2254 8007001f 00000000 x32dbg!CrashDumpFatal+0x47 [e:\projects\x64_dbg\x64_dbg_exe\crashdump.cpp @ 40]
00d3c9d0 011c127a 00d3c9f8 00d3ca2c 77286846 x32dbg!CrashDumpCreate+0x185 [e:\projects\x64_dbg\x64_dbg_exe\crashdump.cpp @ 87]
00d3c9dc 77286846 00d3c9f8 00d3cb28 00d3cad8 x32dbg!CrashDumpVectoredHandler+0x1a [e:\projects\x64_dbg\x64_dbg_exe\crashdump.cpp @ 101]
00d3ca2c 772ed8e1 00000000 00d3d000 00000000 ntdll!RtlpCallVectoredHandlers+0xba
00d3cac0 772c09bf 00d3cad8 00d3cb28 00d3cad8 ntdll!RtlDispatchException+0x72
00d3cac0 74f9b61d 00d3cad8 00d3cb28 00d3cad8 ntdll!KiUserExceptionDispatcher+0xf
00d3cf94 53ab838f 00d3d000 00000000 00000002 msvcrt!memcpy+0x198
00d3cfb0 53ab7332 00000000 00000000 00000000 dbghelp!ReadImageData+0x4c
00d3d370 53ab6bc7 c3fd9543 7b5d4800 7b605bb8 dbghelp!ReadHeader+0x171
00d3d3a8 53ab5afe c3fd9ea3 750c0000 00000000 dbghelp!imgReadLoaded+0xad
00d3d848 53ab611c 76bd2170 00ae4740 00000000 dbghelp!modload+0x1a6
00d3dcbc 53aafb3a 00000000 750c0000 00000000 dbghelp!LoadModule+0x309
00d3dd18 507c22c8 00002964 00002afc 00ae4740 dbghelp!SymLoadModuleEx+0x45
00d3dd50 507c6510 00002964 00002afc 00d3e6d4 x32dbg_50790000!SafeSymLoadModuleEx+0x38 [e:\projects\x64_dbg\x64_dbg_dbg\dbghelp_safe.cpp @ 76]
00d3ede4 53c5e4c2 53cbb6dc 507c43e0 507c43e0 x32dbg_50790000!cbLoadDll+0x160 [e:\projects\x64_dbg\x64_dbg_dbg\debugger.cpp @ 839]
WARNING: Stack unwind information not available. Following frames may be wrong.
00d3fb58 507c48fb c0c5a406 00d3fc70 508c14a8 TitanEngine!DebugLoop+0x1ad2
00d3fc9c 76ba7c04 508c2558 76ba7be0 e682a121 x32dbg_50790000!threadDebugLoop+0x51b [e:\projects\x64_dbg\x64_dbg_dbg\debugger.cpp @ 1184]
00d3fcb0 772db54f 508c2558 e773911e 00000000 KERNEL32!BaseThreadInitThunk+0x24
00d3fcf8 772db51a ffffffff 772c0404 00000000 ntdll!__RtlUserThreadStart+0x2f
00d3fd08 00000000 507c43e0 508c2558 00000000 ntdll!_RtlUserThreadStart+0x1b
@Nukem9

This comment has been minimized.

Member

Nukem9 commented Jul 14, 2015

I can't cause it to crash any longer. ba63ac3 seems to have fixed it. Just waiting for your confirmation.

@wk-952

This comment has been minimized.

wk-952 commented Jul 14, 2015

i'll try it now and edit this post correspondingly.

EDIT: yep :)
reached 110 restarts with symbols present and no problems, i'll try later today more restart attempts but you can close this issue already if you want.
Thank you everyone so much.

@Nukem9 Nukem9 closed this Jul 14, 2015

@mrexodia

This comment has been minimized.

Member

mrexodia commented Jul 14, 2015

amazings! hopefully the bugs stay away from now on 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment