I have a VB6 app that runs on thousands of machines. On a very small number of these I'm getting a "This application has stopped working" error. I've seen it on Vista, Windows 7 (x32 and x64) and Windows 8.1.
I've narrowed it down to occurring sometime between the first form_resize event and the actual painting of the form during the first redraw of the main window. It's happening somewhere out of my VB6 code somewhere as I cannot catch the error and all the logging I've put in is useless. For example, if the application starts up with the main window visible it crashes. If it starts up minimized it runs run until you activate the window and then it crashes. Today I managed to get a crash dump off of a clients computer (because, of course we can never get it to crash on our dev machines). Here's what WinDBG is telling me. I'd appreciate (ANY) help as I've been trying to get to the bottom of this since 2012 (!!!!!!).
FOLLOWUP_IP:
msvbvm60!Zombie_Release+1233b
72960d94 8901 mov dword ptr [ecx],eax
APP: timeclockmts.exe
ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) x86fre
PRIMARY_PROBLEM_CLASS: WRONG_SYMBOLS
BUGCHECK_STR: APPLICATION_FAULT_WRONG_SYMBOLS
LAST_CONTROL_TRANSFER: from 72a09a7b to 72960d94
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
00097504 72a09a7b 01396b8c 4fb934ec 60030053 msvbvm60!Zombie_Release+0x1233b
00097544 72a09c2c 01396b8c 00000009 00000000 msvbvm60!BASIC_DISPINTERFACE_GetTypeInfo+0x2aa
00097574 758c370d 01396b8c 00000009 75870630 msvbvm60!EVENT_SINK_Invoke+0x50
000975cc 7589c30e 00000000 000273c9 0b0dcb40 oleaut32!VarMonthName+0x11350
000975e0 758c41e5 00000001 00000002 00000000 oleaut32!VarDecNeg+0x5d45
000975f4 729932c4 0b0dcb40 000273c9 00000000 oleaut32!VarMonthName+0x11e28
00097628 72973db1 0523c0dc 00000012 4180923a msvbvm60!IID_IVbaHost+0x24c84
0009767c 729c1e19 0000000d 4180923a 0523bebc msvbvm60!IID_IVbaHost+0x5771
000976b8 729acdb0 0000000d 4180923a 05221380 msvbvm60!IID_IVbaHost+0x537d9
000976f4 729ad0a1 0523c0dc 0000000d 4180923a msvbvm60!IID_IVbaHost+0x3e770
00097728 72980eed 034a0904 0000000d 00000001 msvbvm60!IID_IVbaHost+0x3ea61
00097988 4fbadfdb 01396a70 000979fc 000979f4 msvbvm60!IID_IVbaHost+0x128ad
00097a20 4fbaa41a 01396a70 0009834c 00098478 ciaXPLabel30!DllCanUnloadNow+0x10efd
00097a5c 75873e75 01396a70 0b0ee654 00000000 ciaXPLabel30!DllCanUnloadNow+0xd33c
00097a78 72a16ef5 01396b8c 0000001c 00000004 oleaut32!DispCallFunc+0xa6
000983d4 72a09a7b 01396b8c 4fb934ec 60030053 msvbvm60!_vbaAptOffset+0x68b
00098414 72a09c2c 01396b8c 00000009 00000000 msvbvm60!BASIC_DISPINTERFACE_GetTypeInfo+0x2aa
00098444 758c370d 01396b8c 00000009 75870630 msvbvm60!EVENT_SINK_Invoke+0x50
0009849c 7589c30e 00000000 000273c9 0b0dcb40 oleaut32!VarMonthName+0x11350
000984b0 758c41e5 00000001 00000002 00000000 oleaut32!VarDecNeg+0x5d45
000984c4 729932c4 0b0dcb40 000273c9 00000000 oleaut32!VarMonthName+0x11e28
000984f8 72973db1 0523c0dc 00000012 4180923a msvbvm60!IID_IVbaHost+0x24c84
Thanks to blabb who taught me how to fix up my symbols and re-run the analysis the reason for my crash became obvious. Unfortunately I'd already worked that out myself by trial and error (removing controls from a form one at a time until the crash stopped occurring). Here's the lines of the crash dump that told me what was happening:
00097a20 4fbaa41a 01396a70 0009834c 00098478 ciaXPLabel30!DllCanUnloadNow+0x10efd
00097a5c 75873e75 01396a70 0b0ee654 00000000 ciaXPLabel30!DllCanUnloadNow+0xd33c
The complete log looks like an endless loop of this control trying to dispose of itself. I've ditched the control and now things are working nicely.
Related
I want having a deep dive into ntdll!NtQueueApcThread seeing what happen after syscall instruction is executed. According to the document(Intel® 64 and IA-32 Architectures Software Developer’s Manual), the syscall instruction using the msr's LSTAR (0xC0000082) as the rip, so I set breakpoint in the nt!KiSystemCall64, which is the address I got by "rdmsr c0000082". But it's not working, my debugger doesn't break. It seems that the syscall inst does not jump to the address stored in the msr.
This is what I have done:
0: kd>
ntdll!NtQueueApcThread+0x10:
0033:00007ffb`3c32c640 7503 jne ntdll!NtQueueApcThread+0x15 (00007ffb`3c32c645)
0: kd>
ntdll!NtQueueApcThread+0x12:
0033:00007ffb`3c32c642 0f05 syscall
0: kd> rdmsr c0000082
msr[c0000082] = fffff802`3681e6c0
0: kd> u fffff802`3681e6c0
nt!KiSystemCall64:
fffff802`3681e6c0 0f01f8 swapgs
fffff802`3681e6c3 654889242510000000 mov qword ptr gs:[10h],rsp
fffff802`3681e6cc 65488b2425a8010000 mov rsp,qword ptr gs:[1A8h]
fffff802`3681e6d5 6a2b push 2Bh
fffff802`3681e6d7 65ff342510000000 push qword ptr gs:[10h]
fffff802`3681e6df 4153 push r11
fffff802`3681e6e1 6a33 push 33h
fffff802`3681e6e3 51 push rcx
0: kd> bp ffff802`3681e6c0
0: kd> t
ntdll!NtQueueApcThread+0x14:
0033:00007ffb`3c32c644 c3 ret
the target system version is Windows10 build 19042
After a few day study, I got to know what the problem is. In normal situation, setting a breakpoint in nt!KiSystemCall64 will cause a BSOD, this is because the first three instruction in nt!KiSystemCall64 is setting the kernel stack, which is required by windows kernel debugging mechanism. So the solution is setting the breakoint after the kernel stack is setup
bp nt!KiSystemCall64+0x15
In my situation, setting breakpoint does nothing happend, seems like the breakpoint is not working, I guess it is due to the anti-virus software I installed, which may have hooked some thing. After I uninstalled it, breakpoint is worked.
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
Everyone.
I help out with I.T. for a medical practice. It turns out there’s a bug in the EMR software which shows up once in a while. (All the computers run on Windows 10 currently)
The program dies and I get the popup “A problem has caused the program to stop working…”
I hook up a debugger. It looks like a heap issue in their code according to the stack trace. I turn on GFlags and it hits every time. I tell the EMR Software folks but they don’t like to claim bugs and want to prove it’s not them.
They boot the computer to Safe Mode with Networking and low and behold there’s no heap problem so they say they’re off the hook. It’s not them.
I’ve reproduced the problem on all the machines (32 and 64 bit) and in Clean Mode and logged in under the activated Administrator account but Safe Mode works every time.
I've reproduced the problem by running in a command window:
gflags /p /enable emrprogram.exe /full
cdb -g -x emrname.exe
Questions:
How can Safe Mode make a heap bug disappear?
Any suggestions for reproducing the bug in Safe Mode, i.e. what’s really happening in Safe Mode Can I make it more like Normal Mode?
P.S. Here's the stack trace:
VERIFIER STOP 00000010: pid 0x238: corrupted start stamp
04F61000 : Heap handle
0014F09C : Heap block
00000000 : Block size
00000000 : Corrupted stamp
0:000> kb
ChildEBP RetAddr Args to Child
0014ed20 5fa0aac9 00000010 5fa01bc8 04f61000 verifier!VerifierStopMessage+0x27e
0014ed84 5fa0ae8a 04f61000 00000004 0014f09c
verifier!AVrfpDphReportCorruptedBlock+0x239
0014ede0 5fa0b3c2 04f61000 0014f09c 00000004 verifier!AVrfpDphCheckNormalHeapBlock+0x11a
0014ee00 5fa09cf3 04f61000 05230000 01000002 verifier!AVrfpDphNormalHeapFree+0x22
0014ee24 77d76c42 04f60000 01000002 0014f09c verifier!AVrfDebugPageHeapFree+0xe3
0014ee84 77cca934 0014f09c 014b1fe2 04f60000 ntdll!RtlDebugFreeHeap+0x3c
0014ef40 77cc9238 00000000 0014f09c 44ce6ff8 ntdll!RtlpFreeHeap+0xb4
*** ERROR: Module load completed but symbols could not be loaded for image00400000
0014ef68 01f3d902 04f60000 00000000 0014f09c ntdll!RtlFreeHeap+0x268
WARNING: Stack unwind information not available. Following frames may be wrong.
0014f0b8 01f3c6c6 0014f1dc 08f58f70 0dab2f88 image00400000+0x1b3d902
0014f21c 01f3c4b9 0dab2f88 0014f2d8 08f58f70 image00400000+0x1b3c6c6
0014f320 02053935 0dab2f88 0014f454 0014f500 image00400000+0x1b3c4b9
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\SYSTEM32\MSVBVM60.DLL -
0014f4f4 66051d33 08f58f70 0014f510 0051c783 image00400000+0x1c53935
0014f510 66052034 0051c783 0014f57c 00000002 MSVBVM60!IID_IVbaHost+0x236f3
0014f528 6605211a 08f58fe8 0014f6c4 0014f57c MSVBVM60!IID_IVbaHost+0x239f4
0014f6cc 77b3b3cc 00000009 0659b040 00000000 MSVBVM60!IID_IVbaHost+0x23ada
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files\emrname\IGThreed40.ocx -
0014f72c 2411bead 0c7e0fac 00000016 241343f8 GDI32!ScriptStringAnalyzeGlyphs+0x2cc
0014f98c 2410ae97 0c71fd60 2413794c 0c71fff0 IGThreed40!DLLGetDocumentation+0x27d1
0014f9a4 24116fda 09f4b6fc 16fa9fd4 759fb0ff IGThreed40+0xae97
0014f9c8 759dc807 0c71fff0 000001cc 00000004 IGThreed40+0x16fda
0014fc70 2411b679 0cac5638 0c71fff0 fffffdd9 OLEAUT32!CTypeInfo2::Invoke+0x517
0014fc9c 24106d11 0c71fd60 fffffdd9 0cac5638 IGThreed40!DLLGetDocumentation+0x1f9d
0014fcd0 241179f6 0c71fd60 fffffdd9 6601aea8 IGThreed40+0x6d11
0014fcfc 66049039 0c71fd60 fffffdd9 6601aea8 IGThreed40+0x179f6
0014fd44 66049a8a 0c7e0e8c 08baaf0c 0000000d MSVBVM60!IID_IVbaHost+0x1a9f9
0014fd74 66083900 0c7e0e8c 000a037e 0000104d MSVBVM60!IID_IVbaHost+0x1b44a
0014fd9c 66083d58 08b8ce6c 0014fe50 00000001 MSVBVM60!IID_IVbaHost+0x552c0
0014fdd8 6601ca5e 08b8ce6c 00c8030c 7552d390 MSVBVM60!IID_IVbaHost+0x55718
0014fe08 6600a782 0014fe50 ffffffff 6600a72e MSVBVM60!Zombie_Release+0xe005
0014fe34 6600a6b0 07097f8c 0014fe50 ffffffff MSVBVM60!_vbaStrToAnsi+0x3ab
0014fe78 6600a63f ffffffff 07097f8c 07080000 MSVBVM60!_vbaStrToAnsi+0x2d9
0014febc 6600a51d 0709dfcc ffffffff 00000238 MSVBVM60!_vbaStrToAnsi+0x268
0014fed8 6600a4e8 07097f88 0709dfcc ffffffff MSVBVM60!_vbaStrToAnsi+0x146
0014fefc 66003644 ffffffff 03f40670 03f40670 MSVBVM60!_vbaStrToAnsi+0x111
0014ff78 00489fca 004a30b4 779995f4 0020d000 MSVBVM60!ThunRTMain+0xa0
0014ff94 77cb241a 0020d000 014b0f7e 00000000 image00400000+0x89fca
0014ffdc 77cb23e9 ffffffff 77d339e7 00000000 ntdll!__RtlUserThreadStart+0x2b
0014ffec 00000000 03f40670 0020d000 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000>
The gist of the problem is : What are the possibilities of a user-land app getting corrupted while it is running ? Other than hardware failures.
Hardware rig : ARM9 (at91sam9xe)
NAND Flash for :Linux kernel + FS + userland app.
We had an app running on embedded linux on ARM9 (at91sam9xe ), there were no problems for a couple of months but then suddenly an ARM reported being unable to execute the app..
When it was executed it crashed with the following dump :
pgd = c16b8000
[00000020] *pgd=215a0031, *pte=00000000, *ppte=00000000
Pid: 349, comm: console
CPU: 0 Not tainted (2.6.30.4-uc0 #280)
PC is at 0x4e000
LR is at 0x673e0
pc : [<0004e000>] lr : [<000673e0>] psr: 60000010
sp : bec6a728 ip : bec6acb4 fp : bec6ac9c
r10: 000bd9f8 r9 : 00000000 r8 : 00000000
r7 : 00000000 r6 : bec6acb4 r5 : 00000000 r4 : fbad2084
r3 : ffffffff r2 : bec6acb4 r1 : 00000025 r0 : 0009eab0
Flags: nZCv IRQs on FIQs on Mode USER_32 ISA ARM Segment user
Control: 0005317f Table: 216b8000 DAC: 00000015
[<c02ec3b0>] (show_regs+0x0/0x50) from [<c02f11a8>] (__do_user_fault+0x9c/0xa8)
r5:0000000b r4:c1696360
[<c02f110c>] (__do_user_fault+0x0/0xa8) from [<c02f1344>] (do_page_fault+0x114/0x244)
r7:00010000 r6:c1696360 r5:c15a62e0 r4:c1c5fde0
[<c02f1230>] (do_page_fault+0x0/0x244) from [<c02ea284>] (do_DataAbort+0x3c/0xa0)
[<c02ea248>] (do_DataAbort+0x0/0xa0) from [<c02eae00>] (ret_from_exception+0x0/0x10)
Exception stack(0xc1683fb0 to 0xc1683ff8)
3fa0: 0009eab0 00000025 bec6acb4 ffffffff
3fc0: fbad2084 00000000 bec6acb4 00000000 00000000 00000000 000bd9f8 bec6ac9c
3fe0: bec6acb4 bec6a728 000673e0 0004e000 60000010 ffffffff
I tried addr2line to see where it crashed but it gave reference to crtstuff.c =\ crtstuff.c is not a part of our app, its related to GCC i think.
I feared corruption of my executable, so i ran a diff on the file on NAND and file from my PC... there were differences which shouldn't happen. Plus, the differences were almost all of them as "0x00" values instead of the value they should contain.
What I really want to know is , how can a userland app get corrupted other than the hardware failures ?
Cause:
NAND flash was always writeable , so what we hypohtesized was that there is a coincidence where things are being written to flash and power goes out .
Solution
Moved our FS to RAM, we only mount part of NAND partition as writeable only when there is a need to write something. NAND write protect was controlled via Hardware Pin to only enable when there is a write-request from App
First let me say I am a total WinDbg noob, so this might be an easy question...
I have an application ("MyApp" - name changed to protect the innocent!) that I am trying to debug because it is throwing an exception. This only happens on user machines - I have not been able to reproduce it on my development machine. So I set up DebugDiag on the users machine and captured a Full Dump. Then I loaded the dump in WinDbg and did an analyze -v and a kp to try to figure out what was going on... but neither of these seem to give me the information that I'm looking for - the function (and hopefully the line number) of the line that is causing the problem... I think I have the symbol file loaded by specifying the path to 'MyApp.pdb' in the Symbol File Path:
srv*c:\symcache*http://msdl.microsoft.com/download/symbols;srv*c:\symcache*C:\dev\Customer\MyAppSln\MyApp\Debug
First, here's the output from kp:
0:004> kp
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
0502f474 7c347966 MyApp!DllMain+0x3e8a6
0502f4bc 7c3a2448 msvcr71!_nh_malloc(unsigned int size = <Memory access error>, int nhFlag = <Memory access error>)+0x24 [f:\vs70builds\3052\vc\crtbld\crt\src\malloc.c # 117]
0502f57c 7c3416b3 msvcp71!std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::_Tidy(bool _Built = <Memory access error>, unsigned int _Newsize = <Memory access error>)+0x45 [f:\vs70builds\3077\vc\crtbld\crt\src\xstring # 1520]
0502f610 7c3a32de msvcr71!_heap_alloc(unsigned int size = <Memory access error>)+0xe0 [f:\vs70builds\3052\vc\crtbld\crt\src\malloc.c # 212]
0502f620 7c3b3f63 msvcp71!wmemcpy(wchar_t * _S1 = 0x04e463b9 "Ҹ???", wchar_t * _S2 = 0xffffffff "--- memory read error at address 0xffffffff ---", unsigned int _N = 0x4e25212)+0x14 [f:\vs70builds\3077\vc\crtbld\crt\src\wchar.h # 843]
0502f640 04e463b9 msvcp71!std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::assign(class std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > * _Right = 0xffffffff, unsigned int _Roff = 0x4e25212, unsigned int _Count = 2)+0x7c [f:\vs70builds\3077\vc\crtbld\crt\src\xstring # 601]
0502f770 04df1077 MyApp!DllMain+0x65329
0502f824 04e01b35 MyApp!DllMain+0xffe7
0502ff08 04dfe034 MyApp!DllMain+0x20aa5
0502ff48 04dfde4f MyApp!DllMain+0x1cfa4
0502ff88 7648d0e9 MyApp!DllMain+0x1cdbf
0502ffc4 773499f9 kernel32!BaseThreadInitThunk+0xe
0502ffd4 7738198e ntdll!RtlQueryInformationAcl+0x8b
0502ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
the line I'm specifically trying to decode is the 'MyApp!DllMain+0x65329' as this is the last line that seems to be executing, and the error is occurring within the malloc call, which is apparently where the exception is being thrown from. What am I doing wrong that makes it only display the module and offset instead of source file and line number?
I'm also not sure why the line above the malloc call is back in MyApp again - maybe someone can explain that too.
Just in case, here's the output from 'analyze -v':
0:004> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
*** WARNING: Unable to verify checksum for MyApp.exe
*** ERROR: Module load completed but symbols could not be loaded for MyApp.exe
*** WARNING: Unable to verify checksum for ThirdPartyDll.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ThirdPartyDll.dll -
*** WARNING: Unable to verify checksum for mdnsNSP.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols for mdnsNSP.dll -
*** ERROR: Symbol file could not be found. Defaulted to export symbols for SLC.dll -
FAULTING_IP:
MyApp!DllMain+3e8a6
04e1f936 8b16 mov edx,dword ptr [esi]
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 04e1f936 (MyApp!DllMain+0x0003e8a6)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000000
Parameter[1]: 00000000
Attempt to read from address 00000000
PROCESS_NAME: MyApp.exe
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".
EXCEPTION_PARAMETER1: 00000000
EXCEPTION_PARAMETER2: 00000000
READ_ADDRESS: 00000000
FOLLOWUP_IP:
msvcr71!_heap_alloc+e0 [f:\vs70builds\3052\vc\crtbld\crt\src\malloc.c # 212]
7c3416b3 e88e0c0000 call msvcr71!__SEH_epilog (7c342346)
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
LAST_CONTROL_TRANSFER: from 00000000 to 773bbb33
FAULTING_THREAD: ffffffff
BUGCHECK_STR: APPLICATION_FAULT_ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_NULL_POINTER_READ_SHUTDOWN
PRIMARY_PROBLEM_CLASS: ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_SHUTDOWN
DEFAULT_BUCKET_ID: ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_SHUTDOWN
STACK_TEXT:
773bbb33 ntdll!RtlpAllocateHeap+0x7ad
773a6e0c ntdll!RtlAllocateHeap+0x1e3
7c3416b3 msvcr71!_heap_alloc+0xe0
FAULTING_SOURCE_CODE:
No source found for 'f:\vs70builds\3052\vc\crtbld\crt\src\malloc.c'
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: msvcr71!_heap_alloc+e0
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: msvcr71
IMAGE_NAME: msvcr71.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 3e561eac
STACK_COMMAND: dds 7740c078 ; kb
FAILURE_BUCKET_ID: ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_SHUTDOWN_c0000005_msvcr71.dll!_heap_alloc
BUCKET_ID: APPLICATION_FAULT_ACTIONABLE_HEAP_CORRUPTION_heap_failure_freelists_corruption_NULL_POINTER_READ_SHUTDOWN_msvcr71!_heap_alloc+e0
If you believe the PDB should be in your symbol path, you should run something like this:
!sym noisy
.reload MyApp.dll
kp
!sym noisy causes the debugger to give out more detailed information on why it couldn't load symbols - no MyApp.pdb found, found but does not match, etc. This will help you find out why it is not loading symbols. !sym noisy again turns off the verbose symbol output.
When you set the path for symbols, did you reload them?
.reload
I'm not sure your adding
srv*c:\symcache*C:\dev\Customer\MyAppSln\MyApp\Debug
to the symbol path has the desired effect.
I usually list all local paths in the .sympath first, and as the last step, I do .symfix+ to configure the public symbols using the microsoft symbol server:
.sympath C:\dev\Customer\MyAppSln\MyApp\Debug
.symfix+ c:\symcache
the rationale behind listing local paths first being that the debugger would not have to check the remote server for pdbs (that are not there anyways) as opposed to simply retrieving them locally.
Anyways, your problem is that the symbols for MyApp are not loaded therefore stack walking does not quite work.
Debugger walks the stack backwards, starting from the top, that's why you're seeing MyApp - this is where the access violation occurred.
Now, since debugger does not have the symbols at this point, it can only guess what invocation chain has led to the function on top.
And it guesses wrong by following a misleading path.