I am making an exe from an existing VB6 project. During Make, VB crashes with the following message
Visual Basic has stopped working
Problem Event Name: APPCRASH
Application Name: vb6.exe
Application Version: 6.0.97.82
Fault Module Name: ntdll.dll
Exception Code: c0000005
I am able to run the project from VB6 without any trouble. The problem occurs when I try to make the exe.
Please could you let me know what could be wrong?
Thanks!
This all needs to be done on the computer with the fault. I cannot load my ntdll.dll as it a different version and the addresses will be different to yours.
Download and install Debugging Tools for Windows
http://msdn.microsoft.com/en-us/windows/hardware/hh852363
Install the Windows SDK but just choose the debugging tools.
Create a folder called Symbols in C:\
This allows WinDbg to get the symbols for your version of ntdll.dll. Start Windbg. File menu - Symbol File Path and enter
srv*C:\symbols*http://msdl.microsoft.com/download/symbols
then
Open ntdll in WinDbg as a crashdump.
It will show the load address.
Type in WinDbg
ln <modloadaddress> + 7c911780
This will give you the nearest symbol to the crash. It probably isn't useful but lets see.
You can also run VB6 under WinDbg (make sure WinDbg is run as admin). When you crash do a stack trace.
Also do an !Analyze when you crash. It is meant for blue screens but will give info on appcrash.
Type in the WinDbg command prompt
!analyze -v
-v stands for Verbose and if the crash was originated by a program, as opposed to hardware or a driver, it will appear in the middle of the listing.
eg
PROCESS_NAME: java.exe
IMAGE_NAME: ntkrnlmp.exe
PROCESS_NAME only appears in the analyze -v output and only if a program originated the call that faulted.
WinDbg Commands
Open as Executable.
windbg -o -g -G c:\windows\system32\cmd.exe /k batfile.bat
You can press F12 to stop it and kb will show the call stack (g continues the program). If there's errors it will also stop and show them.
There is a breakpoint after loading but before any code is run. Press g to continue. Likewise there is a breakpoint after all code has run but before it is unloaded.
Type lm to list loaded modules, x *!* to list the symbols and bp symbolname to set a breakpoint
If programming in VB6 then this environmental variable link=/pdb:none stores the symbols in the dll rather than separate files. Make sure you compile the program with No Optimisations and tick the box for Create Symbolic Debug Info. Both on the Compile tab in the Project's Properties.
Sample output from a nearest symbol search.
Loading Dump File [C:\Windows\System32\ntdll.dll] Symbol search path
is: srvc:\symbolshttp://msdl.microsoft.com/download/symbols
Executable search path is: ModLoad: 4b280000 4b3f9000
C:\Windows\System32\ntdll.dll eax=00000000 ebx=00000000 ecx=00000000
edx=00000000 esi=00000000 edi=00000000 eip=4b280000 esp=00000000
ebp=00000000 iopl=0 nv up di pl nz na pe nc cs=0000 ss=0000
ds=0000 es=0000 fs=0000 gs=0000 efl=00000000
ntdll!__guard_fids_table (ntdll+0x0): 4b280000 4d
dec ebp 0:000> ln 4b280000 + 65534 (4b2e5520)
ntdll!RtlInitializeBitMap+0x14 | (4b2e5540)
ntdll!TpCallbackUnloadDllOnCompletion
Sample stack trace.
You follow what function called what functions. So you read it from the bottom up. It has the first 4 parameters that were passed to the function. You find the debugger starts additional threads so we need to find our program's one.
~
Lists all threads
~<threadid> e <command>
Do a KB on all threads until you find the main one.
0:004> ~0 e kb
ChildEBP RetAddr Args to Child 04bdfc30
75ae325a 04bdfc70 00000000 00000000 USER32!NtUserGetMessage+0xc
04bdfc4c 00895eb6 04bdfc70 00000000 00000000 USER32!GetMessageW+0x2a
04bdfc8c 008a5b41 00890000 00000000 04e2336f notepad!WinMain+0xe6
04bdfd20 74ad3744 7f229000 74ad3720 10fde46e
notepad!WinMainCRTStartup+0x151 04bdfd34 7755a064 7f229000 b0c1107f
00000000 KERNEL32!BaseThreadInitThunk+0x24 04bdfd7c 7755a02f ffffffff
7757d7c9 00000000 ntdll!__RtlUserThreadStart+0x2f 04bdfd8c 00000000
008a59f0 7f229000 00000000 ntdll!_RtlUserThreadStart+0x1b
Assume that 04bdfc70 is an HWnd. Which it is because the documentation says so. But assume it an address of a string. This displays what is there.
ds 775a1300
or to look at the values
db 775a1300
Related
While using Application Verifier and windbg to debug one of my VSTO addins, I found out that on Word close I get the following stop:
VERIFIER STOP 00000902: pid 0x3F1C: An HKEY was leaked.
00000632 : Value of the leaked HKEY.
0422EA9C : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
1D3F6FE8 : Address of the owner dll name. Run du <address> to read the dll name.
74040000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
What is the best way to find out the cause of this stop?
Following the advice I did dps 0422EA9C
and the following was returned:
0422ea9c 0423f164
0422eaa0 0000e001
0422eaa4 001c0000
0422eaa8 740f3da0 vfbasics!AVrfpRegOpenKeyW+0xb0
0422eaac 74041e54 oledlg!CStringCache::Init+0x47
0422eab0 74041b51 oledlg!DllMain+0x2e
0422eab4 74041869 oledlg!_CRT_INIT+0x26d
0422eab8 7415c66d verifier!AVrfpStandardDllEntryPointRoutine+0x99
0422eabc 741c95fa vrfcore!VfCoreStandardDllEntryPointRoutine+0x12a
0422eac0 740e7904 vfbasics!AVrfpStandardDllEntryPointRoutine+0xa4
0422eac4 77698d04 ntdll!LdrpCallInitRoutine+0x14
0422eac8 7769c23d ntdll!LdrpRunInitializeRoutines+0x26f
0422eacc 7769aeb5 ntdll!LdrpLoadDll+0x453
0422ead0 7769afcc ntdll!LdrLoadDll+0xaa
0422ead4 740e7d2d vfbasics!AVrfpLdrLoadDll+0x5d
0422ead8 75072ca8 KERNELBASE!LoadLibraryExW+0x1f7
0422eadc 74e548f4 kernel32!LoadLibraryW+0x11
0422eae0 741a6871 vstoee!DllGetClassObject+0x4320
0422eae4 741a68a1 vstoee!DllGetClassObject+0x4350
0422eae8 6b5bfca5 mso!Ordinal4378+0x8dc
0422eaec 6ac85248 mso!MsoFLongSave+0xaa353
0422eaf0 6a686ddd mso!Ordinal9769+0x60b
0422eaf4 6a68667a mso!Ordinal1832+0x13b
0422eaf8 6be22bbb wwlib!DllGetClassObject+0x5dbef
0422eafc 6bdc7c2f wwlib!DllGetClassObject+0x2c63
0422eb00 6bdc4a4b wwlib!FMain+0x253
0422eb04 013815c4 winword+0x15c4
0422eb08 01381558 winword+0x1558
0422eb0c 74e5337a kernel32!BaseThreadInitThunk+0xe
0422eb10 776992b2 ntdll!__RtlUserThreadStart+0x70
0422eb14 77699285 ntdll!_RtlUserThreadStart+0x1b
0422eb18 00000000
Then du 1D3F6FE8
returned
1d3f6fe8 "oledlg.dll"
Interestingly, If I run Application Verifier / WinDbg on Word without my addin loaded I still get a stop:
APPLICATION_VERIFIER_LEAK_ALLOCATION (900)
A heap allocation was leaked.
This stop is generated if the owner dll of the allocation was dynamically unloaded while owning resources.
Arguments:
Arg1: 0b7e2fb8, Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
Arg2: 041495f4, Address to the allocation stack trace. Run dps <address> to view the allocation stack.
Arg3: 0c446fe4, Address of the owner dll name. Run du <address> to read the dll name.
Arg4: 70b50000, Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
GetPageUrlData failed, server returned HTTP status 404
URL requested: http://watson.microsoft.com/StageOne/winword_exe/15_0_4737_1003/559b7227/vrfcore_dll/10_0_15063_137/f4688fdb/80000003/00003809.htm?Retriage=1
Is this the same thing but reported differently?
I looked deeper into this as the very helpful comments above pointed me to think this is not an issue with my addin code but rather with the VSTO host application ie. Word.
So I created a simple VSTO addin with a one button ribbon that just opens a taskpane with a label which says “Hello!” (nothing else – no WPF) and I can confirm that even in this scenario I still get the HKEY Leak on shutdown…
For completeness, when no addins are loaded I get a different stop:
=======================================
VERIFIER STOP 0000000000000300: pid 0x4008: Invalid handle exception for current stack trace.
00000000C0000008 : Exception code.
000000000F9DE670 : Exception record. Use .exr to display it.
000000000F9DE180 : Context record. Use .cxr to display it.
0000000000000000 : Not used.
=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.
=======================================
ModLoad: 711a0000 711c5000 C:\windows\SysWOW64\POWRPROF.DLL
=======================================
VERIFIER STOP 00000900: pid 0x4008: A heap allocation was leaked.
0BDCCFB8 : Address of the leaked allocation. Run !heap -p -a <address> to get additional information about the allocation.
041D9C54 : Address to the allocation stack trace. Run dps <address> to view the allocation stack.
0C36AFE4 : Address of the owner dll name. Run du <address> to read the dll name.
749C0000 : Base of the owner dll. Run .reload <dll_name> = <address> to reload the owner dll. Use 'lm' to get more information about the loaded and unloaded modules.
=======================================
!avrf suggests a APPLICATION_VERIFIER_LEAK_ALLOCATION (900) so I don't think this is a problem with anything but Application Verifier.
Here is the crash i found in the log shown by Windbg. but not able to get anything out of it. please help.
00000000`0008ae08 00000000`76eb219e wow64cpu!CpupSyscallStub+0x2
00000000`0008ae10 00000000`76e7219a wow64cpu!Thunk0ArgReloadState+0x5
00000000`0008aec0 00000000`76e79b14 wow64!RunCpuSimulation+0xa
00000000`0008af10 00000000`76ed840f wow64!Wow64KiUserCallbackDispatcher+0x244
00000000`0008b270 00007ff9`ac2c3044 wow64win!whcbfnINOUTSTYLECHANGE+0xbf
00000000`0008bc50 00000000`76ee9a7a ntdll!KiUserCallbackDispatcherContinue
00000000`0008bcd8 00000000`76ed7a74 wow64win!NtUserSetWindowLongPtr+0xa
00000000`0008bce0 00000000`76e6a44b wow64win!whNtUserSetWindowLong+0x44
00000000`0008bd10 00000000`76eb1dc5 wow64!Wow64SystemServiceEx+0xfb
00000000`0008c5c0 00000000`76e7219a wow64cpu!ServiceNoTurbo+0xb
00000000`0008c670 00000000`76e79b14 wow64!RunCpuSimulation+0xa
00000000`0008c6c0 00000000`76ed880e wow64!Wow64KiUserCallbackDispatcher+0x244
00000000`0008ca20 00007ff9`ac2c3044 wow64win!whcbfnINOUTNCCALCSIZE+0x14e
00000000`0008d470 00000000`76eb2352 ntdll!KiUserCallbackDispatcherContinue
00000000`0008d558 00000000`76eb2318 wow64cpu!CpupSyscallStub+0x2
00000000`0008d560 00000000`76e7219a wow64cpu!Thunk0Arg+0x5
00000000`0008d610 00000000`76e79b14 wow64!RunCpuSimulation+0xa
00000000`0008d660 00000000`76ed5c0a wow64!Wow64KiUserCallbackDispatcher+0x244
00000000`0008d9c0 00007ff9`ac2c3044 wow64win!whcbfnDWORD+0x21a
00000000`0008e3c0 00000000`76ee5a3a ntdll!KiUserCallbackDispatcherContinue
00000000`0008e448 00000000`76ed6df2 wow64win!NtUserMessageCall+0xa
00000000`0008e450 00000000`76ed6b64 wow64win!whNT32NtUserMessageCallCB+0x32
00000000`0008e4a0 00000000`76e6a44b wow64win!whNtUserMessageCall+0xc4
00000000`0008e560 00000000`76eb1dc5 wow64!Wow64SystemServiceEx+0xfb
00000000`0008ee10 00000000`76e7219a wow64cpu!ServiceNoTurbo+0xb
00000000`0008eec0 00000000`76e720d2 wow64!RunCpuSimulation+0xa
00000000`0008ef10 00007ff9`ac2f3a15 wow64!Wow64LdrpInitialize+0x172
00000000`0008f450 00007ff9`ac2d2f1e ntdll!LdrpInitializeProcess+0x1591
00000000`0008f770 00007ff9`ac248ece ntdll!_LdrpInitialize+0x89ffe
00000000`0008f7e0 00000000`00000000 ntdll!LdrInitializeThunk+0xe
As others have mentioned, you have a 64 bit dump of a 32 bit process. We can see this because your excerpt shows 64 bit addresses and it has the wow64 module in the stack.
Typically you should try to get a dump of the correct bitness. The linked SO answer lists several options to get one.
Opening the dump file in the x86 version of WinDbg does not help. Even the x86 version can analyze 64 bit dumps:
The !sw command (load it with .load wow64exts) or the .effmach x86 command can switch the debugger to x86 mode. Note how the command prompt changes:
To show the call stack, you'll now need the wow64exts extension. Also be sure to have set the symbols:
.load wow64exts
.symfix
.reload
Note that there is one call stack per thread, so make sure you get the right one:
~#s
k
In case of a crash, look at the exception:
.exr -1
I am trying kernel debugging using vmware and windbg.I have connected two OS and all symbols are loaded successfully.If I want to see my driver in memory how can I disassembly that?
I have tried lm commands and lmvm commands
kd> lmvm comint32
start end module name
88da9000 88daf000 comint32 (private pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\comint32.pdb\653387D894B4412FA9E30659E58DD47C1\comint32.pdb
Loaded symbol image file: comint32.sys
Image path: \SystemRoot\System32\Drivers\comint32.sys
Image name: comint32.sys
Timestamp: Thu Apr 11 20:10:55 2013 (51677B3F)
CheckSum: 0000CACF
ImageSize: 00006000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
x comint32!* should dump all the symbols of the module along with their addresses in memory.
You can then either use the u command (with the name (e.g. comint32!DriverEntry) or the address of a function as a parameter) to disassemble into the main window or you can open the disassembly window and paste the name/address into it and browse the disassembled code there.
See your windbg reference for further details.
I'm working on porting Mumble over to Windows RT (using the jailbreak), and I've hit an issue where this one function is getting corrupted when Mumble loads.
Mumble (Corrupt function):
0:000> dq user32.dll+0x023918
77a63918 47c3004244696841 4770df010c16f241
77a63928 4770df010c17f241 4770df010c18f241
77a63938 4770df010c19f241 4770df010c1af241
77a63948 4770df010c1bf241 4770df010c1cf241
77a63958 4770df010c1df241 4770df010c1ef241
77a63968 4770df010c1ff241 4770df015c81f44f
77a63978 4770df010c21f241 4770df010c22f241
77a63988 4770df010c23f241 4770df010c24f241
0:000> u user32.dll+0x023918
* ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\windows\system32\user32.dll -
user32!WindowFromPoint:
77a63918 6841 ldr r1,[r0,#4]
77a6391a 4469 add r1,r1,sp
77a6391c 0042 lsls r2,r0,#1
77a6391e 47c3 ?blx r8
77a63920 f2410c16 mov r12,#0x1016
77a63924 df01 svc #1
TeXworks (Expected output):
0:000> dq user32.dll+0x23918
77a63918 4770df010c15f241 4770df010c16f241
77a63928 4770df010c17f241 4770df010c18f241
77a63938 4770df010c19f241 4770df010c1af241
77a63948 4770df010c1bf241 4770df010c1cf241
77a63958 4770df010c1df241 4770df010c1ef241
77a63968 4770df010c1ff241 4770df015c81f44f
77a63978 4770df010c21f241 4770df010c22f241
77a63988 4770df010c23f241 4770df010c24f241
0:000> u user32.dll+0x23918
* ERROR: Symbol file could not be found. Defaulted to export symbols for C:\windows\system32\USER32.dll -
USER32!WindowFromPoint:
77a63918 f2410c15 mov r12,#0x1015
77a6391c df01 svc #1
77a6391e 4770 bx lr
77a63920 f2410c16 mov r12,#0x1016
77a63924 df01 svc #1
77a63926 4770 bx lr
77a63928 f2410c17 mov r12,#0x1017
77a6392c df01 svc #1
(Apologies for the less than stellar formatting of the code, a screenshot of the windows can be found here: http://i.imgur.com/M6mLHN1.png )
Mumble uses Qt (customized by the Mumble team, to my understanding), Protobuf, Boost, and OpenSSL
TeXworks uses Qt
What I've tried so far:
Disabling the application compatibility engine
Unloading user32.dll at load, then reloading it (calling FreeLibrary 100 times, then calling LoadLibrary)
Removing anything that might look even remotely suspect from the manifests (from Qt and Mumble)
Removing the entire manifests (from Qt and Mumble)
If I patch this one function using cdb after Mumble launches it all works awesomely, but if I don't patch it the first action performed that calls that function ends in a crash. Opening/closing windows and dragging all call that function, so it's rather critical to the program that it's there.
Any help or pointers on this would be more than appreciated.
Edit: I've verified that it's something inside mainCRTStartup that's mucking around with it, trying to figure out what exactly it is now.
Edit 2: Found a platform-specific hook hidden in the Mumble code that was causing my troubles. Solved.
Since I can finally answer this now, Mumble had some hooks hidden away that I didn't know about. I defined a custom entrypoint that called mainCRTStartup so I could step through that and find exactly where that memory was getting changed, it led me straight to the hook.
Here's the code I used for that:
EXTERN_C int WINAPI mainCRTStartup();
void __stdcall EntryPoint()
{
MessageBox(HWND_DESKTOP,L"Pause(Before mainCRTStartup)",L"Pause(Before mainCRTStartup",MB_OK);
mainCRTStartup();
ExitProcess(0);
}
That allowed me to attach a debugger at the messagebox and step through mainCRTStartup until I found the static initializer that was getting called to load the hook.
here is what I'm trying to solve. I have a crash dump from Google Chrome.
I open windbg and say File -> Symbol File Path:
"SRV*c:\code\symbols*http://msdl.microsoft.com/download/symbols;SRV*c:\code\symbols*https://chromium-browser-symsrv.commondatastorage.googleapis.com"
I guess this looks for the debugging symbols from let to right and should finally grab them from google then. I copied that from http://www.chromium.org/developers/how-tos/debugging.
I drag and drop the crash dump into windbg
And then...
Microsoft (R) Windows Debugger Version 6.2.8400.0 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\cburgdorf\Desktop\Chrome-last.dmp]
User Mini Dump File: Only registers, stack and portions of memory are available
Symbol search path is: SRV*c:\code\symbols*http://msdl.microsoft.com/download/symbols;SRV*c:\code\symbols*https://chromium-browser-symsrv.commondatastorage.googleapis.com
Executable search path is:
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Wed May 16 16:25:24.000 2012 (UTC + 2:00)
System Uptime: not available
Process Uptime: 0 days 0:01:39.000
.........................................
This dump file has a breakpoint exception stored in it.
The stored exception information can be accessed via .ecxr.
eax=00000000 ebx=0038e1f8 ecx=00000001 edx=0012df58 esi=00000002 edi=0038e218
eip=776e013d esp=0038e1a8 ebp=0038e244 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00200246
ntdll!NtWaitForMultipleObjects+0x15:
776e013d 83c404 add esp,4
0:000> .excr
^ Syntax error in '.excr'
You see that it says "The stored exception information can be accessed via .ecxr" but once I insert that it tells me that I have a syntax error.
Does anyone know what I'm doing wrong?
You've got a typo, it's .ecxr :) In the meantime, another easy way to get information out of a crash dump without needing too much WinDbg-fu, is:
.symfix; .reload
!analyze -v
And if this is a .NET App (Chromium isn't but just for extra info), add these three lines
.loadby sos clr
!pe
~*e !clrstack