Analysing a minidump cause by a release build

Discussion:

(too old to reply)

Peter

2009-07-09 00:29:31 UTC

I have a problem in that the release build of our application (a large,
multi-threaded windows service) crashes on a production machine. I
configured the system such that it now creates a mini crash dump.

I've been trying to use WinDbg to analyse the dump but frankly, I get
nowhere. It shows me 20 running threads and I can look at the stack for each
thread, but I have no idea what functions are on the stack let alone what
the arguments are. I think the core of my problem is a lack of symbol file:

*** ERROR: Module load completed but symbols could not be loaded for
APALSvc-TEST.exe

I'm also aware that WinDbg can use symbol files, but I thought the VC++ /Zi
switch only applied to debug builds.

Can anybody give me a pointer that would help me move on?

Hepas of thanks for any help
Pete

BTW: I do have a map file, but I don't know how to correlate its content to
the crash dump. Please tell me that I don't need to do this.

==========
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [D:\Temp\new.dmp]
User Mini Dump File with Full Memory: Only application data is available

Symbol search path is:
drv*http://msdl.microsoft.com/download/symbols;D:\Test_APAL6\APALSvc\Release_TEST;srv*C:\Temp*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2003 Version 3790 (Service Pack 2) MP (4 procs) Free x86
compatible
Product: Server, suite: Enterprise TerminalServer DataCenter SingleUserTS
Machine Name:
Debug session time: Wed Jul 8 08:06:46.000 2009 (GMT-7)
System Uptime: 27 days 4:22:46.410
Process Uptime: 0 days 0:05:44.000
...........................................................
Missing image name, possible paged-out or corrupt data.
Loading unloaded module list
.Missing image name, possible paged-out or corrupt data.
....
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(12ec.3d90): Access violation - code c0000005 (first/second chance not
available)
eax=0327e538 ebx=0327e638 ecx=00000000 edx=00000000 esi=05142078
edi=0327e6d4
eip=0067017b esp=0327e4ec ebp=0327e654 iopl=0 nv up ei pl zr na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00010246
*** WARNING: Unable to verify checksum for APALSvc-TEST.exe
*** ERROR: Module load completed but symbols could not be loaded for
APALSvc-TEST.exe
APALSvc_TEST+0x27017b:
0067017b 8b4978 mov ecx,dword ptr [ecx+78h]
ds:0023:00000078=????????

Geoff

2009-07-09 03:27:51 UTC

Permalink

Post by Peter
Can anybody give me a pointer that would help me move on?

You don't mention - or I didn't notice what version of VC you are
using.

Set the release project to generate a PDB file. "Generate program
database" in linker options.

Scot T Brennecke

2009-07-10 07:04:02 UTC

Permalink

Post by Peter
I have a problem in that the release build of our application (a large,
multi-threaded windows service) crashes on a production machine. I
configured the system such that it now creates a mini crash dump.
I've been trying to use WinDbg to analyse the dump but frankly, I get
nowhere. It shows me 20 running threads and I can look at the stack for each
thread, but I have no idea what functions are on the stack let alone what
*** ERROR: Module load completed but symbols could not be loaded for
APALSvc-TEST.exe
I'm also aware that WinDbg can use symbol files, but I thought the VC++ /Zi
switch only applied to debug builds.
Can anybody give me a pointer that would help me move on?
Hepas of thanks for any help
Pete
BTW: I do have a map file, but I don't know how to correlate its content to
the crash dump. Please tell me that I don't need to do this.
==========
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [D:\Temp\new.dmp]
User Mini Dump File with Full Memory: Only application data is available
drv*http://msdl.microsoft.com/download/symbols;D:\Test_APAL6\APALSvc\Release_TEST;srv*C:\Temp*http://msdl.microsoft.com/download/symbols
Windows Server 2003 Version 3790 (Service Pack 2) MP (4 procs) Free x86
compatible
Product: Server, suite: Enterprise TerminalServer DataCenter SingleUserTS
Debug session time: Wed Jul 8 08:06:46.000 2009 (GMT-7)
System Uptime: 27 days 4:22:46.410
Process Uptime: 0 days 0:05:44.000
...........................................................
Missing image name, possible paged-out or corrupt data.
Loading unloaded module list
.Missing image name, possible paged-out or corrupt data.
....
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(12ec.3d90): Access violation - code c0000005 (first/second chance not
available)
eax=0327e538 ebx=0327e638 ecx=00000000 edx=00000000 esi=05142078
edi=0327e6d4
eip=0067017b esp=0327e4ec ebp=0327e654 iopl=0 nv up ei pl zr na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00010246
*** WARNING: Unable to verify checksum for APALSvc-TEST.exe
*** ERROR: Module load completed but symbols could not be loaded for
APALSvc-TEST.exe
0067017b 8b4978 mov ecx,dword ptr [ecx+78h]
ds:0023:00000078=????????

As Geoff said, you can create a PDB for release builds; it's not just for debug.
Use the /Zi switch for compile, and the /DEBUG switch on the link:
http://msdn.microsoft.com/en-us/library/xe4t6fc1.aspx

Your access violation is caused by a NULL pointer reference. It appears that you have an object type (probably a class) with an
embedded member at offset 0x78 within that class. It seems you are trying to execute a line of code that accesses that embedded
member and calls a method of that member. However, the pointer to enclosing object (the "this" pointer) is NULL. So the attempt to
access the member causes a access violation.

Peter

2009-07-23 02:10:58 UTC

Permalink

In the meantime I've gone through heaps of literature on the subject on the
net. While I learned heaps, I'm still struggling to get this beast under
control.

I guess from our perspective, the most interesting way of creating minidumps
is by calling the DbgHelp API MiniDumpWriteDump inside the application. The
problem is, it doesn't always fire.

Attached is a small application that uses it. In the main app you can see
two statements which both cause a fatal errors: one error is reported by the
Visual Studio debugger as a "Fatal C Runtime Library Error" and the other as
a "C++ Access Violation Exception".

The test application only produces a minidump for the second error.

Sure, this is already better than nothing, but is there a way to trap all
unhandled errors?

Pete

Post by Scot T Brennecke

Post by Peter
I have a problem in that the release build of our application (a large,
multi-threaded windows service) crashes on a production machine. I
configured the system such that it now creates a mini crash dump.
I've been trying to use WinDbg to analyse the dump but frankly, I get
nowhere. It shows me 20 running threads and I can look at the stack for
each thread, but I have no idea what functions are on the stack let alone
what the arguments are. I think the core of my problem is a lack of
*** ERROR: Module load completed but symbols could not be loaded for
APALSvc-TEST.exe
I'm also aware that WinDbg can use symbol files, but I thought the VC++
/Zi switch only applied to debug builds.
Can anybody give me a pointer that would help me move on?
Hepas of thanks for any help
Pete
BTW: I do have a map file, but I don't know how to correlate its content
to the crash dump. Please tell me that I don't need to do this.
==========
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [D:\Temp\new.dmp]
User Mini Dump File with Full Memory: Only application data is available
drv*http://msdl.microsoft.com/download/symbols;D:\Test_APAL6\APALSvc\Release_TEST;srv*C:\Temp*http://msdl.microsoft.com/download/symbols
Windows Server 2003 Version 3790 (Service Pack 2) MP (4 procs) Free x86
compatible
Product: Server, suite: Enterprise TerminalServer DataCenter SingleUserTS
Debug session time: Wed Jul 8 08:06:46.000 2009 (GMT-7)
System Uptime: 27 days 4:22:46.410
Process Uptime: 0 days 0:05:44.000
...........................................................
Missing image name, possible paged-out or corrupt data.
Loading unloaded module list
.Missing image name, possible paged-out or corrupt data.
....
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(12ec.3d90): Access violation - code c0000005 (first/second chance not
available)
eax=0327e538 ebx=0327e638 ecx=00000000 edx=00000000 esi=05142078
edi=0327e6d4
eip=0067017b esp=0327e4ec ebp=0327e654 iopl=0 nv up ei pl zr na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
*** WARNING: Unable to verify checksum for APALSvc-TEST.exe
*** ERROR: Module load completed but symbols could not be loaded for
APALSvc-TEST.exe
0067017b 8b4978 mov ecx,dword ptr [ecx+78h]
ds:0023:00000078=????????

As Geoff said, you can create a PDB for release builds; it's not just for debug.
http://msdn.microsoft.com/en-us/library/xe4t6fc1.aspx
Your access violation is caused by a NULL pointer reference. It appears
that you have an object type (probably a class) with an embedded member at
offset 0x78 within that class. It seems you are trying to execute a line
of code that accesses that embedded member and calls a method of that
member. However, the pointer to enclosing object (the "this" pointer) is
NULL. So the attempt to access the member causes a access violation.

Peter

2009-07-23 02:21:57 UTC

Permalink

OOps, here is the attachment!

Post by Peter
In the meantime I've gone through heaps of literature on the subject on the
net. While I learned heaps, I'm still struggling to get this beast under
control.
I guess from our perspective, the most interesting way of creating minidumps
is by calling the DbgHelp API MiniDumpWriteDump inside the application. The
problem is, it doesn't always fire.
Attached is a small application that uses it. In the main app you can see
two statements which both cause a fatal errors: one error is reported by the
Visual Studio debugger as a "Fatal C Runtime Library Error" and the other as
a "C++ Access Violation Exception".
The test application only produces a minidump for the second error.
Sure, this is already better than nothing, but is there a way to trap all
unhandled errors?
Pete

Post by Scot T Brennecke

Post by Peter
I have a problem in that the release build of our application (a large,
multi-threaded windows service) crashes on a production machine. I
configured the system such that it now creates a mini crash dump.
I've been trying to use WinDbg to analyse the dump but frankly, I get
nowhere. It shows me 20 running threads and I can look at the stack for
each thread, but I have no idea what functions are on the stack let alone
what the arguments are. I think the core of my problem is a lack of
*** ERROR: Module load completed but symbols could not be loaded for
APALSvc-TEST.exe
I'm also aware that WinDbg can use symbol files, but I thought the VC++
/Zi switch only applied to debug builds.
Can anybody give me a pointer that would help me move on?
Hepas of thanks for any help
Pete
BTW: I do have a map file, but I don't know how to correlate its content
to the crash dump. Please tell me that I don't need to do this.
==========
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [D:\Temp\new.dmp]
User Mini Dump File with Full Memory: Only application data is available
drv*http://msdl.microsoft.com/download/symbols;D:\Test_APAL6\APALSvc\Release_TEST;srv*C:\Temp*http://msdl.microsoft.com/download/symbols
Windows Server 2003 Version 3790 (Service Pack 2) MP (4 procs) Free x86
compatible
Product: Server, suite: Enterprise TerminalServer DataCenter
SingleUserTS
Debug session time: Wed Jul 8 08:06:46.000 2009 (GMT-7)
System Uptime: 27 days 4:22:46.410
Process Uptime: 0 days 0:05:44.000
...........................................................
Missing image name, possible paged-out or corrupt data.
Loading unloaded module list
.Missing image name, possible paged-out or corrupt data.
....
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(12ec.3d90): Access violation - code c0000005 (first/second chance not
available)
eax=0327e538 ebx=0327e638 ecx=00000000 edx=00000000 esi=05142078
edi=0327e6d4
eip=0067017b esp=0327e4ec ebp=0327e654 iopl=0 nv up ei pl zr na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
*** WARNING: Unable to verify checksum for APALSvc-TEST.exe
*** ERROR: Module load completed but symbols could not be loaded for
APALSvc-TEST.exe
0067017b 8b4978 mov ecx,dword ptr [ecx+78h]
ds:0023:00000078=????????

begin 666 Sandbox.cpp
M(V1E9FEN92!724XS,E],14%.7T%.1%]-14%.#0HC:6YC;'5D92 \=VEN9&]W
M<RYH/@T*#0HC:6YC;'5D92 B9&)G:&5L<"YH(@T*#0HC:6YC;'5D92 \<W1R
M:6YG/@T*(VEN8VQU9&4@/&EO<W1R96%M/@T*#0IU<VEN9R!N86UE<W!A8V4@
M<W1D.PT*#0IS=')I;F<)"4=?<W1R07!P4&%T:#L-"G-T<FEN9PD)1U]S=')!
M<'!.86UE.PT*#0H-"@T*=F]I9"!3971!<'!0871H*"D-"GL-"@EC:&%R"0D)
M"0D)"7-Z07!P4&%T:%M?34%87U!!5$A=.PT*"7-T<FEN9PD)"0D)"7-T<D%P
M<%!A=&@[#0H)<W1R:6YG.CIS:7IE7W1Y<&4)<&]S1DY-+"!P;W-%6%0[#0H)
M<W1R:6YG"0D)"0D)<W1R1DX[#0H-"@T*"6EF("A'971-;V1U;&5&:6QE3F%M
M92@@3E5,3"P@<WI!<'!0871H+"!?34%87U!!5$@@*2D-"@E[#0H)"7-T<D%P
M<%!A=&@@/2!S>D%P<%!A=&@[#0H-"@D)+R\@1&5T97)M:6YE(&%P<&QI8V%T
M:6]N('!A=&@-"@D)<&]S1DY-(#T@<W1R07!P4&%T:"YR9FEN9"@G7%PG*3L-
M"@T*"0EI9B H<&]S1DY-(#T]('-T<FEN9SHZ;G!O<RD-"@D)"7!O<T9.32 ]
M('-T<D%P<%!A=&@N;&5N9W1H*"D[#0H-"@D)1U]S=')!<'!0871H(#T@<W1R
M07!P4&%T:"YS=6)S='(H,"P@<&]S1DY-("L@,2D[#0H-"@D)+R\@1&5T97)M
M:6YE(&%P<&QI8V%T:6]N(&YA;64-"@D)<&]S15A4(#T@<W1R07!P4&%T:"YR
M9FEN9"@G+B<I.PT*#0H)"6EF("AP;W-%6%0@/3T@<W1R:6YG.CIN<&]S('Q\
M('!O<T585" \('!O<T9.32D-"@D)"7!O<T9.32 ]('-T<D%P<%!A=&@N;&5N
M9W1H*"D[#0H-"@D)1U]S=')!<'!.86UE(#T@<W1R07!P4&%T:"YS=6)S='(H
M<&]S1DY-("L@,2P@<&]S15A4("T@<&]S1DY-("T@,2D[#0H)?0T*#0H):68@
M*$=?<W1R07!P4&%T:"YE;7!T>***@I*2!'7W-T<D%P<%!A=&@@/2 B+EQ<(CL-
M"@EI9B H1U]S=')!<'!.86UE+F5M<'1Y*"DI($=?<W1R07!P3F%M92 ](")U
M;FMW;F%P<"([#0H-"@EC;W5T(#P\(")0871H.B G(B \/"!'7W-T<D%P<%!A
M=&@@/#P@(B=<;B([#0H)8V]U=" \/" B07!P.B @)R(@/#***@1U]S=')!<'!.
M86UE(#P\("(G7&XB.PT*?0T*#0H-"@T*#0I,3TY'(%=)3D%022!7<FET94-R
M87-H1'5M<"AS=')***@7T580T505$E/3E]03TE.5$524R J<$5X8V5P=&EO
M;DEN9F\@*0T*>PT*"6-O=70@/#P@(E=R:71E0W)A<VA$=6UP('-T87)T960N
M7&XB.PT*"4A73D0)"0EH4&%R96YT(#***@3E5,3#L-"@E,3TY'"0D)<F5T=F%L
M(#***@15A#15!424].7T-/3E1)3E5%7U-%05)#2#L-"@ES=')I;F<)"7-T<E1E
M;7 [#0H-"@T*"7-T<E1E;7 @/2!'7W-T<D%P<%!A=&@@*R B9&)G:&5L<"YD
M;&PB.PT*"7-T<E1E;7 @/2!'7W-T<D%P<%!A=&@@*R!'7W-T<D%P<$YA;64@
M*R B+F1M<"([#0H-"@E(04Y$3$4@:$9I;&4@/2!#<F5A=&5&:6QE*'-T<E1E
M;7 N8U]S='(H****@1T5.15))0U]***@1DE,15]32$%215]74DE412P@
M3E5,3"***@0U)%051%7T%,5T%***@1DE,15]!5%1224)55$5?3D]234%,+"!.
M54Q,("D[#0H-"@EI9B H:$9I;&4A/4E.5D%,241?2$%.1$Q%7U9!3%5%*0T*
M"7L-"@D)7TU)3DE$54U07T580T505$E/3E])3D9/4DU!5$E/3B!%>$EN9F\[
M#0H-"@D)17A);F9O+E1H<F5A9$ED(#***@.CI'971#=7)R96YT5&AR96%D260H
M*3L-"@D)17A);F9O+D5X8V5P=&EO;E!O:6YT97)S(#T@<$5X8V5P=&EO;DEN
M9F\[#0H)"45X26YF;RY#;&EE;G10;VEN=&5R<R ]($Y53$P[#0H-"@D)+R\@
M=W)I=&4@=&AE(&1U;7 -"@D):68@*$UI;FE$=6UP5W)I=&5$=6UP*"!'971#
M=7)R96YT4')O8V5S<***@I+"!'971#=7)R96YT4')O8V5S<TED*"DL(&A&:6QE
M+"!-:6YI1'5M<$YO<FUA;"P@)D5X26YF;***@3E5,3"***@3E5,3" I*0T*"0E[
M#0H)"0EC;W5T(#P\(")'96YE<F%***@36EN:41U;7 Z("(@/#P@<W1R5&5M
M<" \/"!E;F1L.PT*"0D)<F5T=F%L(#***@15A#15!424].7T5814-55$5?2$%.
M1$Q%4CL-"@D)?0T*#0H)"4-L;W-E2&%N9&QE*&A&:6QE*3L-"@E]#0H-"@EC
M;W5T(#P\(")7<FET94-R87-H1'5M<"!F:6YI<VAE9"Y<;B([#0H)<F5T=7)N
M(')E='9A;#L-"GT-"@T*#0H-"@T*:6YT(&UA:6XH:6YT(&%R9V,L(&-H87(J
M(&%R9W9;72D-"GL-"@E3971!<'!0871H*"D[#0H)4V5T17)R;W)-;V1E*%-%
M35].3T=01D%53%1%4E)/4D)/6"D[#0H)4V5T56YH86YD;&5D17AC97!T:6]N
M1FEL=&5R*%=R:71E0W)A<VA$=6UP*3L-"@T*"7-T<FEN9PES='([#0H)<W1R
M:6YG"2IP4W1R(#***@3E5,3#L-"@T*"7-T<BYE;F0H*2LK.PD)+R\@=&AI<R!E
M<G)O<B!C875S97,@82!&871A;"!#+5)U;G1I;***@3&EB<F%R>2!%<G)O<B!A
M;***@9&]E<R!N;W0@<')O9'5C92!A($UI;FE$=6UP#0H)*G!3='(@/2 B1U!&
M(CL)+R\@=&AI<R!E<G)O<B!C875S97,@82!#****@06-C97-S(%9I;VQA=&EO
M;B!A;F0@<')O9'5C97,@82!-:6YI1'5M< T*#0H)+R\@5V4G;&P@;F5V97(@
M9V5T(&AE<F4-"@EC;W5T(#P\(")O:UQN(CL-"@T*"7)E='5R;B P.PT*?0T*
"#0H`
`
end

UOAR

2009-07-23 06:24:01 UTC

Permalink

Even I'm facing the exact same problem.
My application is crashing at the customer site every now and then giving
runtime error. somehow the dmp or drwtsn32 is not getting generated for this
error.
I tried using dbghelp's MiniDumpWriteDump() but its of no use in this case.
People say if you link debug version of library to a release build this
happens. But I'm not sure about that cause in my case everything is linked
properly - my vc 6 dlls to vc library of release builds.

I'm really sorry Peter if you think I've hijacked your thread. I thought it
would be helpful if you come to know that you are not the only one facing
this problem ;)

Post by Peter
OOps, here is the attachment!

Post by Scot T Brennecke

Post by Peter
I have a problem in that the release build of our application (a large,
multi-threaded windows service) crashes on a production machine. I
configured the system such that it now creates a mini crash dump.
I've been trying to use WinDbg to analyse the dump but frankly, I get
nowhere. It shows me 20 running threads and I can look at the stack for
each thread, but I have no idea what functions are on the stack let alone
what the arguments are. I think the core of my problem is a lack of
*** ERROR: Module load completed but symbols could not be loaded for
APALSvc-TEST.exe
I'm also aware that WinDbg can use symbol files, but I thought the VC++
/Zi switch only applied to debug builds.
Can anybody give me a pointer that would help me move on?
Hepas of thanks for any help
Pete
BTW: I do have a map file, but I don't know how to correlate its content
to the crash dump. Please tell me that I don't need to do this.
==========
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [D:\Temp\new.dmp]
User Mini Dump File with Full Memory: Only application data is available
drv*http://msdl.microsoft.com/download/symbols;D:\Test_APAL6\APALSvc\Release_TEST;srv*C:\Temp*http://msdl.microsoft.com/download/symbols
Windows Server 2003 Version 3790 (Service Pack 2) MP (4 procs) Free x86
compatible
Product: Server, suite: Enterprise TerminalServer DataCenter SingleUserTS
Debug session time: Wed Jul 8 08:06:46.000 2009 (GMT-7)
System Uptime: 27 days 4:22:46.410
Process Uptime: 0 days 0:05:44.000
...........................................................
Missing image name, possible paged-out or corrupt data.
Loading unloaded module list
.Missing image name, possible paged-out or corrupt data.
....
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(12ec.3d90): Access violation - code c0000005 (first/second chance not
available)
eax=0327e538 ebx=0327e638 ecx=00000000 edx=00000000 esi=05142078
edi=0327e6d4
eip=0067017b esp=0327e4ec ebp=0327e654 iopl=0 nv up ei pl zr na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
*** WARNING: Unable to verify checksum for APALSvc-TEST.exe
*** ERROR: Module load completed but symbols could not be loaded for
APALSvc-TEST.exe
0067017b 8b4978 mov ecx,dword ptr [ecx+78h]
ds:0023:00000078=????????

Martin T.

2009-07-23 10:33:34 UTC

Permalink

I see no attachment? Maybe you'll better inline the code?

Post by Peter
two statements which both cause a fatal errors: one error is reported by the
Visual Studio debugger as a "Fatal C Runtime Library Error" and the other as
a "C++ Access Violation Exception".
The test application only produces a minidump for the second error.
Sure, this is already better than nothing, but is there a way to trap all
unhandled errors?

In my experience, there are some errors that are never handled. Example
being certain cases of stack overflows, where the process that
encounters the problem apparently is terminated immediately by the OS
without anything being executed at all.

Maybe see an old thread here:
http://groups.google.com/group/microsoft.public.vc.debugger/browse_frm/thread/fe7f63ba857ee66f/4f0bea4eb7e612f7

br,
Martin

Peter

2009-07-23 23:21:27 UTC

Permalink

Hi Martin,

Thanks for the pointer which led to interesting reading. I don't think the
iterator bug I built into my code causes a stack overflow or my unhandled
exception filter.

Errors like incrementing/decrementing stl iterators beyond their boundaries
is clearly something I would love to be able to trap. After all, VS 2005
Express can trap the error I built into my code example correctly and show
me the exact location of the problem so there clearly is a way to handle
this case.

Interesting is that if I remove the line:

SetErrorMode(SEM_NOGPFAULTERRORBOX);

from my code sample, and then run the app I get the WER dialog. I can also
see that the WER process wrote a minidump to my Local Settings\Temp folder,
but access to it is denied (I can't even copy it). If I click "Debug..." the
minidump disappears. On my machine the WER dialog is owned by a process
DWWIN which doesn't even show in task manager.

So I thought I'd use WinDbg as my JIT debugger like this:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug

Debugger="C:\Program Files\Debugging Tools for Windows\windbg.exe" -p %ld -e
%ld -g -c '.dump /o /ma c:\TEMP\new.dmp; q' -Q -QS -QY -QSY
Auto=1

I then executed my test program again and this time Windbg kicked in instead
of WER and wrote the c:\temp\new.dmp file. However, the content of it was
really rather useless as the only stack trace I got was:

ntdll!DbgBreakPoint+0x1
ntdll!DbgUiRemoteBreakIn+0x2d

Looking at the modules tells me that all symbols for all modulules are
present in the form of PDB's, so not a lack of symbol fault.

It is this minidump I'm interested in. I don't want it sent to Microsoft, I
want it myself and I don't want the user to be prompted for it either.

Also, I have tried using a __try/__except SEH handler where the minidump is
produced by the __except, but this has not changed the result.

Pete

Post by Martin T.

I see no attachment? Maybe you'll better inline the code?

Post by Peter
two statements which both cause a fatal errors: one error is reported by
the Visual Studio debugger as a "Fatal C Runtime Library Error" and the
other as a "C++ Access Violation Exception".
The test application only produces a minidump for the second error.
Sure, this is already better than nothing, but is there a way to trap all
unhandled errors?

In my experience, there are some errors that are never handled. Example
being certain cases of stack overflows, where the process that encounters
the problem apparently is terminated immediately by the OS without
anything being executed at all.
http://groups.google.com/group/microsoft.public.vc.debugger/browse_frm/thread/fe7f63ba857ee66f/4f0bea4eb7e612f7
br,
Martin

Scot T Brennecke

2009-07-25 18:46:48 UTC

Permalink

Pete,
Since you got a .dmp file generated from the .dump /ma command, you have a complete picture of the process at the time of the dump
creation. You indicate that you see only one call stack. How well-experienced are you with using WinDbg? If it's new to you, then
perhaps you are unaware of some of the commands that will let you survey the stacks of other threads. I suspect this is a
multi-threaded app, and maybe you're only looking at one of the call stacks?

The command "~" (just the tilde on a line by itself) will display a summary of all the running threads at the time of the dump.
Using "~ns" (where n is the number of a thread, and s is really the letter s) will change the context to that thread.
The "k" commands (there are numerous variations, like kb, kp, kbn, kpn, etc.) will display the call stack in a variety of ways.

Let me know if i'm barking up the wrong tree here, or if you need more guidance in using WinDbg. There's a pretty good help file
that comes with it that details all of this.

Post by Peter
Hi Martin,
Thanks for the pointer which led to interesting reading. I don't think the
iterator bug I built into my code causes a stack overflow or my unhandled
exception filter.
Errors like incrementing/decrementing stl iterators beyond their boundaries
is clearly something I would love to be able to trap. After all, VS 2005
Express can trap the error I built into my code example correctly and show
me the exact location of the problem so there clearly is a way to handle
this case.
SetErrorMode(SEM_NOGPFAULTERRORBOX);
from my code sample, and then run the app I get the WER dialog. I can also
see that the WER process wrote a minidump to my Local Settings\Temp folder,
but access to it is denied (I can't even copy it). If I click "Debug..." the
minidump disappears. On my machine the WER dialog is owned by a process
DWWIN which doesn't even show in task manager.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug
Debugger="C:\Program Files\Debugging Tools for Windows\windbg.exe" -p %ld -e
%ld -g -c '.dump /o /ma c:\TEMP\new.dmp; q' -Q -QS -QY -QSY
Auto=1
I then executed my test program again and this time Windbg kicked in instead
of WER and wrote the c:\temp\new.dmp file. However, the content of it was
ntdll!DbgBreakPoint+0x1
ntdll!DbgUiRemoteBreakIn+0x2d
Looking at the modules tells me that all symbols for all modulules are
present in the form of PDB's, so not a lack of symbol fault.
It is this minidump I'm interested in. I don't want it sent to Microsoft, I
want it myself and I don't want the user to be prompted for it either.
Also, I have tried using a __try/__except SEH handler where the minidump is
produced by the __except, but this has not changed the result.
Pete

Post by Martin T.

I see no attachment? Maybe you'll better inline the code?

Post by Peter
two statements which both cause a fatal errors: one error is reported by
the Visual Studio debugger as a "Fatal C Runtime Library Error" and the
other as a "C++ Access Violation Exception".
The test application only produces a minidump for the second error.
Sure, this is already better than nothing, but is there a way to trap all
unhandled errors?

In my experience, there are some errors that are never handled. Example
being certain cases of stack overflows, where the process that encounters
the problem apparently is terminated immediately by the OS without
anything being executed at all.
http://groups.google.com/group/microsoft.public.vc.debugger/browse_frm/thread/fe7f63ba857ee66f/4f0bea4eb7e612f7
br,
Martin

phil oakleaf

2009-09-05 19:41:35 UTC

Permalink

Post by Scot T Brennecke
Pete,
Since you got a .dmp file generated from the .dump /ma command, you
have a complete picture of the process at the time of the dump
creation. You indicate that you see only one call stack. How
well-experienced are you with using WinDbg? If it's new to you, then
perhaps you are unaware of some of the commands that will let you survey
the stacks of other threads. I suspect this is a multi-threaded app,
and maybe you're only looking at one of the call stacks?
The command "~" (just the tilde on a line by itself) will display a
summary of all the running threads at the time of the dump.
Using "~ns" (where n is the number of a thread, and s is really the
letter s) will change the context to that thread.
The "k" commands (there are numerous variations, like kb, kp, kbn, kpn,
etc.) will display the call stack in a variety of ways.
Let me know if i'm barking up the wrong tree here, or if you need more
guidance in using WinDbg. There's a pretty good help file that comes
with it that details all of this.

Post by Peter
Hi Martin,
Thanks for the pointer which led to interesting reading. I don't think
the iterator bug I built into my code causes a stack overflow or my
unhandled exception filter.
Errors like incrementing/decrementing stl iterators beyond their
boundaries is clearly something I would love to be able to trap. After
all, VS 2005 Express can trap the error I built into my code example
correctly and show me the exact location of the problem so there
clearly is a way to handle this case.
SetErrorMode(SEM_NOGPFAULTERRORBOX);
from my code sample, and then run the app I get the WER dialog. I can
also see that the WER process wrote a minidump to my Local
Settings\Temp folder, but access to it is denied (I can't even copy
it). If I click "Debug..." the minidump disappears. On my machine the
WER dialog is owned by a process DWWIN which doesn't even show in task
manager.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug
Debugger="C:\Program Files\Debugging Tools for Windows\windbg.exe" -p
%ld -e %ld -g -c '.dump /o /ma c:\TEMP\new.dmp; q' -Q -QS -QY -QSY
Auto=1
I then executed my test program again and this time Windbg kicked in
instead of WER and wrote the c:\temp\new.dmp file. However, the
content of it was really rather useless as the only stack trace I got
ntdll!DbgBreakPoint+0x1
ntdll!DbgUiRemoteBreakIn+0x2d
Looking at the modules tells me that all symbols for all modulules are
present in the form of PDB's, so not a lack of symbol fault.
It is this minidump I'm interested in. I don't want it sent to
Microsoft, I want it myself and I don't want the user to be prompted
for it either.
Also, I have tried using a __try/__except SEH handler where the
minidump is produced by the __except, but this has not changed the
result.
Pete

Post by Martin T.

I see no attachment? Maybe you'll better inline the code?

Post by Peter
two statements which both cause a fatal errors: one error is
reported by the Visual Studio debugger as a "Fatal C Runtime Library
Error" and the other as a "C++ Access Violation Exception".
The test application only produces a minidump for the second error.
Sure, this is already better than nothing, but is there a way to
trap all unhandled errors?

In my experience, there are some errors that are never handled.
Example being certain cases of stack overflows, where the process
that encounters the problem apparently is terminated immediately by
the OS without anything being executed at all.
http://groups.google.com/group/microsoft.public.vc.debugger/browse_frm/thread/fe7f63ba857ee66f/4f0bea4eb7e612f7
br,
Martin

I've just started to look into this problem and this is my experience so
far.

I used the MiniDumper class by Andy Pennell
http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx

I've configured the system to generate a DMP file and then use Outlook
to email it back to me. The main thing that the program creates the DMP
file on a crash - what you do with it is up to you.

Compile the release build with
C++ (Program Database)
Linker : Generate Program Database $(TargetDir)$(TargetName).pdb
this makes the PDB file you need when the DMP file comes back. But dont
sent it to the customer.
Keep a copy of the source code and PDB file somewhere and ship the EXE
to the customer.

Program crashes and sends back DMP

Load the DMP file into Visual Studio as a new project.

Press F5 and it will report an error.

Nexst tell VS where the symbol file is
"To load symbols manually
1. Right-click in the Modules window and choose Find Symbols on the
shortcut menu.
2. The debugger searches the symbol path to try to find symbols itself.
If symbols were not found, the Find Symbols dialog box appears. In the
Find Symbols dialog box, locate the symbols file (PDB or DBG file) you
want to load. When the name of the symbols file appears in the File Name
box, click OK.
"
Point the Debugger to the saves version of the PDB file

Then set the source path
• Open the solution properties dialog (right-click on the solution in
the Solution Explorer).
• Open the Common Properties node and select Debug Source Files.
• Remove the files from the “Do not look for these source files” list.
• Click “Apply”.
• You may have to reload the solution to get these new settings applied.

Now VS should have everything it needs to show you where the crash happened.

Only thing I'm missing now is that variables allocated from the heap
dont come back but the local variables all seem to be held.

Note: If you just rebuild your program you will probably find that the
new PDB file does not help with the older release. Moral: Keep EVERY
"PDB" generated for each release of the exe.

Hope this makes sense and helps
Phil