|
|
|
date: Tue, 4 Dec 2007 11:26:02 -0800,
group: microsoft.public.win32.programmer.tools
back
AppVerifier breakpoint when closing VB6 application
Hello,
Another first-time user of AppVerifier and WinDbg here --
We are prepping our application for the VeriTest competency test and right
now have everything under "Basics" checked in AppVerifier. This is a VB6 app
that performs without error when run outside AppVerifier. We get no errors
when running under AppVerifier until we close the application, at which point
we get 2 Breakpoint exceptions. When run in WinDbg, we get several more
exceptions, some at the start of the app execution and some at the end. I
cannot determine at this point if this is an issue with our code or with VB6
(or something else altogether). I would like to start by showing you what
happens in WinDbg when the application opens. It appears we reach a
breakpoint even before all of the modules are loaded. Here it is:
Closing open log file c:\MyAppdevelopment\MyApp\DebugLogs\20071121_1018.log
Opened log file 'c:\MyAppdevelopment\MyApp\debuglogs\log_1103.txt'
Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: C:\MyAppdevelopment\MyApp\MyApp.exe
Symbol search path is:
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols;symsrv*symsrv.dll*C:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
ModLoad: 00400000 004d5000 MyApp.exe
ModLoad: 7c900000 7c9b0000 ntdll.dll
AVRF: MyApp.exe: pid 0x1630: flags 0x80000181: application verifier enabled
ModLoad: 5ad10000 5ad56000 C:\WINDOWS\System32\verifier.dll
ModLoad: 00360000 00388000 C:\WINDOWS\System32\vrfcore.dll
ModLoad: 00390000 003c9000 C:\WINDOWS\System32\vfbasics.dll
ModLoad: 7c800000 7c8f5000 C:\WINDOWS\system32\kernel32.dll
AVRF: verifier.dll provider initialized for MyApp.exe with flags 0x80000181
ModLoad: 73420000 73574000 C:\WINDOWS\system32\MSVBVM60.DLL
ModLoad: 7e410000 7e4a0000 C:\WINDOWS\system32\USER32.dll
ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.dll
ModLoad: 77e70000 77f01000 C:\WINDOWS\system32\RPCRT4.dll
ModLoad: 774e0000 7761d000 C:\WINDOWS\system32\ole32.dll
ModLoad: 77c10000 77c68000 C:\WINDOWS\system32\msvcrt.dll
ModLoad: 77120000 771ab000 C:\WINDOWS\system32\OLEAUT32.dll
(1630.1528): Break instruction exception - code 80000003 (first chance)
eax=014e6fec ebx=7ffdf000 ecx=00000001 edx=00000002 esi=014eafb0 edi=014e6fec
eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!DbgBreakPoint:
7c901230 cc int 3
When I hit "g", it loads the rest of the modules. Is the above a breakpoint
coming from ntdll, or is that simply the module that reports errors? I'm
sorry if this is a dumb question, but as a VB developer, you might imagine I
am quite lost looking at all of this "inside stuff" that I thought was being
handled by the runtime.
Any insight would be most appreciated!
Thanks,
Marcia
date: Tue, 4 Dec 2007 11:26:02 -0800
author: Marcia
RE: AppVerifier breakpoint when closing VB6 application
Hi,
The breakpoint you are seeing is the initial break point. When the debugger
starts a new target application,
an initial breakpoint automatically occurs after the main image and all
statically-linked DLLs are loaded but
before any DLL initialization routines are called.
The -g command-line option causes WinDbg or CDB to ignore the initial
breakpoint.
Please search for "initial breakpoint" in debugger help index.
Thanks,
Prasad
"Marcia" wrote:
> Hello,
>
> Another first-time user of AppVerifier and WinDbg here --
>
> We are prepping our application for the VeriTest competency test and right
> now have everything under "Basics" checked in AppVerifier. This is a VB6 app
> that performs without error when run outside AppVerifier. We get no errors
> when running under AppVerifier until we close the application, at which point
> we get 2 Breakpoint exceptions. When run in WinDbg, we get several more
> exceptions, some at the start of the app execution and some at the end. I
> cannot determine at this point if this is an issue with our code or with VB6
> (or something else altogether). I would like to start by showing you what
> happens in WinDbg when the application opens. It appears we reach a
> breakpoint even before all of the modules are loaded. Here it is:
>
> Closing open log file c:\MyAppdevelopment\MyApp\DebugLogs\20071121_1018.log
> Opened log file 'c:\MyAppdevelopment\MyApp\debuglogs\log_1103.txt'
>
> Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
> Copyright (c) Microsoft Corporation. All rights reserved.
>
> CommandLine: C:\MyAppdevelopment\MyApp\MyApp.exe
> Symbol search path is:
> SRV*c:\symbols*http://msdl.microsoft.com/download/symbols;symsrv*symsrv.dll*C:\symbols*http://msdl.microsoft.com/download/symbols
> Executable search path is:
> ModLoad: 00400000 004d5000 MyApp.exe
> ModLoad: 7c900000 7c9b0000 ntdll.dll
> AVRF: MyApp.exe: pid 0x1630: flags 0x80000181: application verifier enabled
> ModLoad: 5ad10000 5ad56000 C:\WINDOWS\System32\verifier.dll
> ModLoad: 00360000 00388000 C:\WINDOWS\System32\vrfcore.dll
> ModLoad: 00390000 003c9000 C:\WINDOWS\System32\vfbasics.dll
> ModLoad: 7c800000 7c8f5000 C:\WINDOWS\system32\kernel32.dll
> AVRF: verifier.dll provider initialized for MyApp.exe with flags 0x80000181
> ModLoad: 73420000 73574000 C:\WINDOWS\system32\MSVBVM60.DLL
> ModLoad: 7e410000 7e4a0000 C:\WINDOWS\system32\USER32.dll
> ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
> ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.dll
> ModLoad: 77e70000 77f01000 C:\WINDOWS\system32\RPCRT4.dll
> ModLoad: 774e0000 7761d000 C:\WINDOWS\system32\ole32.dll
> ModLoad: 77c10000 77c68000 C:\WINDOWS\system32\msvcrt.dll
> ModLoad: 77120000 771ab000 C:\WINDOWS\system32\OLEAUT32.dll
> (1630.1528): Break instruction exception - code 80000003 (first chance)
> eax=014e6fec ebx=7ffdf000 ecx=00000001 edx=00000002 esi=014eafb0 edi=014e6fec
> eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0 nv up ei pl nz na po nc
> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
> ntdll!DbgBreakPoint:
> 7c901230 cc int 3
>
> When I hit "g", it loads the rest of the modules. Is the above a breakpoint
> coming from ntdll, or is that simply the module that reports errors? I'm
> sorry if this is a dumb question, but as a VB developer, you might imagine I
> am quite lost looking at all of this "inside stuff" that I thought was being
> handled by the runtime.
>
> Any insight would be most appreciated!
> Thanks,
> Marcia
date: Tue, 4 Dec 2007 17:53:00 -0800
author: Prasad Kakulamarri [MSFT]
RE: AppVerifier breakpoint when closing VB6 application
Prasad,
Thank you so much for your helpful response. I have another question: is
it safe to assume any breakpoint associated with nt.dll is a breakpoint
caused by the debugger and not something I need to worry about?
"Prasad Kakulamarri [MSFT]" wrote:
> Hi,
> The breakpoint you are seeing is the initial break point. When the debugger
> starts a new target application,
> an initial breakpoint automatically occurs after the main image and all
> statically-linked DLLs are loaded but
> before any DLL initialization routines are called.
> The -g command-line option causes WinDbg or CDB to ignore the initial
> breakpoint.
> Please search for "initial breakpoint" in debugger help index.
>
> Thanks,
> Prasad
>
>
> "Marcia" wrote:
>
> > Hello,
> >
> > Another first-time user of AppVerifier and WinDbg here --
> >
> > We are prepping our application for the VeriTest competency test and right
> > now have everything under "Basics" checked in AppVerifier. This is a VB6 app
> > that performs without error when run outside AppVerifier. We get no errors
> > when running under AppVerifier until we close the application, at which point
> > we get 2 Breakpoint exceptions. When run in WinDbg, we get several more
> > exceptions, some at the start of the app execution and some at the end. I
> > cannot determine at this point if this is an issue with our code or with VB6
> > (or something else altogether). I would like to start by showing you what
> > happens in WinDbg when the application opens. It appears we reach a
> > breakpoint even before all of the modules are loaded. Here it is:
> >
> > Closing open log file c:\MyAppdevelopment\MyApp\DebugLogs\20071121_1018.log
> > Opened log file 'c:\MyAppdevelopment\MyApp\debuglogs\log_1103.txt'
> >
> > Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
> > Copyright (c) Microsoft Corporation. All rights reserved.
> >
> > CommandLine: C:\MyAppdevelopment\MyApp\MyApp.exe
> > Symbol search path is:
> > SRV*c:\symbols*http://msdl.microsoft.com/download/symbols;symsrv*symsrv.dll*C:\symbols*http://msdl.microsoft.com/download/symbols
> > Executable search path is:
> > ModLoad: 00400000 004d5000 MyApp.exe
> > ModLoad: 7c900000 7c9b0000 ntdll.dll
> > AVRF: MyApp.exe: pid 0x1630: flags 0x80000181: application verifier enabled
> > ModLoad: 5ad10000 5ad56000 C:\WINDOWS\System32\verifier.dll
> > ModLoad: 00360000 00388000 C:\WINDOWS\System32\vrfcore.dll
> > ModLoad: 00390000 003c9000 C:\WINDOWS\System32\vfbasics.dll
> > ModLoad: 7c800000 7c8f5000 C:\WINDOWS\system32\kernel32.dll
> > AVRF: verifier.dll provider initialized for MyApp.exe with flags 0x80000181
> > ModLoad: 73420000 73574000 C:\WINDOWS\system32\MSVBVM60.DLL
> > ModLoad: 7e410000 7e4a0000 C:\WINDOWS\system32\USER32.dll
> > ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
> > ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.dll
> > ModLoad: 77e70000 77f01000 C:\WINDOWS\system32\RPCRT4.dll
> > ModLoad: 774e0000 7761d000 C:\WINDOWS\system32\ole32.dll
> > ModLoad: 77c10000 77c68000 C:\WINDOWS\system32\msvcrt.dll
> > ModLoad: 77120000 771ab000 C:\WINDOWS\system32\OLEAUT32.dll
> > (1630.1528): Break instruction exception - code 80000003 (first chance)
> > eax=014e6fec ebx=7ffdf000 ecx=00000001 edx=00000002 esi=014eafb0 edi=014e6fec
> > eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0 nv up ei pl nz na po nc
> > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
> > ntdll!DbgBreakPoint:
> > 7c901230 cc int 3
> >
> > When I hit "g", it loads the rest of the modules. Is the above a breakpoint
> > coming from ntdll, or is that simply the module that reports errors? I'm
> > sorry if this is a dumb question, but as a VB developer, you might imagine I
> > am quite lost looking at all of this "inside stuff" that I thought was being
> > handled by the runtime.
> >
> > Any insight would be most appreciated!
> > Thanks,
> > Marcia
date: Wed, 5 Dec 2007 10:46:04 -0800
author: Marcia
RE: AppVerifier breakpoint when closing VB6 application
Marcia,
You should look at the callstack and find out the reason for the break.
AppVerifier
issues a DbgBreak with a verifier stop message when it encounters an error
in the
application being verified. Since DbgBreak is in ntdll.dll, it appears that
the break
is in ntdll.
In general do not ignore any breaks that the debugger hits...except the
initial break point
and the final break point if the process is exiting normally.
Thanks,
Prasad
"Marcia" wrote:
> Prasad,
>
> Thank you so much for your helpful response. I have another question: is
> it safe to assume any breakpoint associated with nt.dll is a breakpoint
> caused by the debugger and not something I need to worry about?
>
> "Prasad Kakulamarri [MSFT]" wrote:
>
> > Hi,
> > The breakpoint you are seeing is the initial break point. When the debugger
> > starts a new target application,
> > an initial breakpoint automatically occurs after the main image and all
> > statically-linked DLLs are loaded but
> > before any DLL initialization routines are called.
> > The -g command-line option causes WinDbg or CDB to ignore the initial
> > breakpoint.
> > Please search for "initial breakpoint" in debugger help index.
> >
> > Thanks,
> > Prasad
> >
> >
> > "Marcia" wrote:
> >
> > > Hello,
> > >
> > > Another first-time user of AppVerifier and WinDbg here --
> > >
> > > We are prepping our application for the VeriTest competency test and right
> > > now have everything under "Basics" checked in AppVerifier. This is a VB6 app
> > > that performs without error when run outside AppVerifier. We get no errors
> > > when running under AppVerifier until we close the application, at which point
> > > we get 2 Breakpoint exceptions. When run in WinDbg, we get several more
> > > exceptions, some at the start of the app execution and some at the end. I
> > > cannot determine at this point if this is an issue with our code or with VB6
> > > (or something else altogether). I would like to start by showing you what
> > > happens in WinDbg when the application opens. It appears we reach a
> > > breakpoint even before all of the modules are loaded. Here it is:
> > >
> > > Closing open log file c:\MyAppdevelopment\MyApp\DebugLogs\20071121_1018.log
> > > Opened log file 'c:\MyAppdevelopment\MyApp\debuglogs\log_1103.txt'
> > >
> > > Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
> > > Copyright (c) Microsoft Corporation. All rights reserved.
> > >
> > > CommandLine: C:\MyAppdevelopment\MyApp\MyApp.exe
> > > Symbol search path is:
> > > SRV*c:\symbols*http://msdl.microsoft.com/download/symbols;symsrv*symsrv.dll*C:\symbols*http://msdl.microsoft.com/download/symbols
> > > Executable search path is:
> > > ModLoad: 00400000 004d5000 MyApp.exe
> > > ModLoad: 7c900000 7c9b0000 ntdll.dll
> > > AVRF: MyApp.exe: pid 0x1630: flags 0x80000181: application verifier enabled
> > > ModLoad: 5ad10000 5ad56000 C:\WINDOWS\System32\verifier.dll
> > > ModLoad: 00360000 00388000 C:\WINDOWS\System32\vrfcore.dll
> > > ModLoad: 00390000 003c9000 C:\WINDOWS\System32\vfbasics.dll
> > > ModLoad: 7c800000 7c8f5000 C:\WINDOWS\system32\kernel32.dll
> > > AVRF: verifier.dll provider initialized for MyApp.exe with flags 0x80000181
> > > ModLoad: 73420000 73574000 C:\WINDOWS\system32\MSVBVM60.DLL
> > > ModLoad: 7e410000 7e4a0000 C:\WINDOWS\system32\USER32.dll
> > > ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
> > > ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.dll
> > > ModLoad: 77e70000 77f01000 C:\WINDOWS\system32\RPCRT4.dll
> > > ModLoad: 774e0000 7761d000 C:\WINDOWS\system32\ole32.dll
> > > ModLoad: 77c10000 77c68000 C:\WINDOWS\system32\msvcrt.dll
> > > ModLoad: 77120000 771ab000 C:\WINDOWS\system32\OLEAUT32.dll
> > > (1630.1528): Break instruction exception - code 80000003 (first chance)
> > > eax=014e6fec ebx=7ffdf000 ecx=00000001 edx=00000002 esi=014eafb0 edi=014e6fec
> > > eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0 nv up ei pl nz na po nc
> > > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
> > > ntdll!DbgBreakPoint:
> > > 7c901230 cc int 3
> > >
> > > When I hit "g", it loads the rest of the modules. Is the above a breakpoint
> > > coming from ntdll, or is that simply the module that reports errors? I'm
> > > sorry if this is a dumb question, but as a VB developer, you might imagine I
> > > am quite lost looking at all of this "inside stuff" that I thought was being
> > > handled by the runtime.
> > >
> > > Any insight would be most appreciated!
> > > Thanks,
> > > Marcia
date: Thu, 6 Dec 2007 09:59:01 -0800
author: Prasad Kakulamarri [MSFT]
RE: AppVerifier breakpoint when closing VB6 application
Thank you, Prasad. I wonder if I could trouble you a little more.
I am getting 2 breakpoint exceptions from AppVerifier upon closing my
application. I broke into them using WinDbg and got the error messages and
the call stack. It appears to me that the break is perhaps coming from a
module that is out of my control. I'm specifically suspicious of
MSVBVM60.dll. Would you be so kind as to examine the following sequence of 2
breakpoints and tell me if this is coming from my application?
Here is break #1:
(dd0.16c0): Break instruction exception - code 80000003 (!!! second chance
!!!)
eax=000001ff ebx=003a8844 ecx=7c91eb05 edx=000001c0 esi=00000000 edi=000001ff
eip=7c901230 esp=0012f93c ebp=0012fb3c iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!DbgBreakPoint:
7c901230 cc int 3
Call Stack:
# ChildEBP RetAddr
00 0012f938 00363933 ntdll!DbgBreakPoint (FPO: [0,0,0])
01 0012fb3c 003a2fbe vrfcore!VerifierStopMessageEx+0x4bd (FPO: [Non-Fpo])
(CONV: cdecl) [e:\verifier\source\base\avrf\avrf30\vrfcore\sdk.cpp @ 530]
02 0012fb60 003960cd vfbasics!VfBasicsStopMessage+0x8e (FPO: [Non-Fpo])
(CONV: stdcall)
[e:\verifier\source\base\avrf\avrf30\providers\basics\basics.c @ 1066]
03 0012fba8 00399d99 vfbasics!AVrfpFreeMemLockChecks+0x17d (FPO: [Non-Fpo])
(CONV: stdcall)
[e:\verifier\source\base\avrf\avrf30\providers\basics\critsect.c @ 1124]
04 0012fbc4 003a0d6c vfbasics!AVrfpFreeMemNotify+0x39 (FPO: [Non-Fpo])
(CONV: stdcall)
[e:\verifier\source\base\avrf\avrf30\providers\basics\support.c @ 1244]
05 0012fbf0 7c954a69 vfbasics!AVrfpDllUnloadCallback+0x2c (FPO: [Non-Fpo])
(CONV: stdcall) [e:\verifier\source\base\avrf\avrf30\providers\basics\dlls.c
@ 452]
06 0012fc14 7c93d4d4 ntdll!AVrfDllUnloadNotification+0x78 (FPO: [Non-Fpo])
07 0012fd00 003a1703 ntdll!LdrUnloadDll+0x2cd (FPO: [Non-Fpo])
08 0012fd18 7c80abf7 vfbasics!AVrfpLdrUnloadDll+0x73 (FPO: [Non-Fpo]) (CONV:
stdcall) [e:\verifier\source\base\avrf\avrf30\providers\basics\dlls.c @ 1297]
09 0012fd2c 77513442 kernel32!FreeLibrary+0x3f (FPO: [Non-Fpo])
0a 0012fd38 77513456
ole32!CClassCache::CDllPathEntry::CFinishObject::Finish+0x2f (FPO: [Non-Fpo])
0b 0012fd4c 77530729 ole32!CClassCache::CFinishComposite::Finish+0x1d (FPO:
[0,0,0])
0c 0012fecc 7752fd6a ole32!CClassCache::CleanUpDllsForProcess+0x1b2 (FPO:
[Non-Fpo])
0d 0012fed0 7752fee4 ole32!ProcessUninitialize+0x37 (FPO: [0,0,0])
0e 0012fee4 774fee88 ole32!wCoUninitialize+0x11b (FPO: [Non-Fpo])
0f 0012ff00 734397bf ole32!CoUninitialize+0x5b (FPO: [Non-Fpo])
10 0012ff0c 73439712 MSVBVM60!InitTermGlobal+0xaa (FPO: [0,0,2])
11 0012ff1c 7343718b MSVBVM60!CThreadPool::TerminateRuntime+0x21
12 0012ff34 7343ba15 MSVBVM60!CVBThreadAction::Stop+0xb0 (FPO: [Uses EBP]
[0,1,4])
13 0012ff40 7342dee0 MSVBVM60!CThreadPool::TerminateThread+0x43 (FPO: [0,0,2])
14 0012ffb8 004076f6 MSVBVM60!ThunRTMain+0xb9
15 0012fff0 00000000 MyApp!__vbaS+0xa
When I hit "Go", I get another break:
(dd0.16c0): Invalid handle - code c0000008 (first chance)
=======================================
VERIFIER STOP 00000300 : pid 0xDD0: Invalid handle exception for current
stack trace.
C0000008 : Exception code.
0012FAD0 : Exception record. Use .exr to display it.
0012FAE4 : Context record. Use .cxr to display it.
00000000 : Not used.
=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.
=======================================
(dd0.16c0): Break instruction exception - code 80000003 (first chance)
eax=000001ff ebx=003a8d08 ecx=7c91eb05 edx=0012f739 esi=00000000 edi=000001ff
eip=7c901230 esp=0012f7c8 ebp=0012f9c8 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!DbgBreakPoint:
7c901230 cc int 3
Call Stack
# ChildEBP RetAddr
00 0012f7c4 00363933 ntdll!DbgBreakPoint (FPO: [0,0,0])
01 0012f9c8 003a3001 vrfcore!VerifierStopMessageEx+0x4bd (FPO: [Non-Fpo])
(CONV: cdecl) [e:\verifier\source\base\avrf\avrf30\vrfcore\sdk.cpp @ 530]
02 0012f9ec 00398f5b vfbasics!VfBasicsStopMessage+0xd1 (FPO: [Non-Fpo])
(CONV: stdcall)
[e:\verifier\source\base\avrf\avrf30\providers\basics\basics.c @ 1071]
03 0012fa20 7c942dcf vfbasics!AVrfpVectoredExceptionHandler+0x9b (FPO:
[Non-Fpo]) (CONV: stdcall)
[e:\verifier\source\base\avrf\avrf30\providers\basics\support.c @ 243]
04 0012fa40 7c9377da ntdll!RtlCallVectoredExceptionHandlers+0x48 (FPO:
[Non-Fpo])
05 0012fab8 7c90eafa ntdll!RtlDispatchException+0x19 (FPO: [Non-Fpo])
06 0012fab8 7c90eb74 ntdll!KiUserExceptionDispatcher+0xe (FPO: [2,0,0])
(CONTEXT @ 0012fae4)
07 0012fe00 7c90eb93 ntdll!KiRaiseUserExceptionDispatcher+0x37
08 0012fe1c 7c81cd6b ntdll!KiFastSystemCallRet+0x4
09 0012ff18 7c81cdee kernel32!_ExitProcess+0x37 (FPO: [Non-Fpo])
0a 0012ff2c 00394e6a kernel32!ExitProcess+0x14
0b 0012ff3c 7342deec vfbasics!AVrfpExitProcess+0x3a (FPO: [Non-Fpo]) (CONV:
stdcall) [e:\verifier\source\base\avrf\avrf30\providers\basics\thread.c @ 205]
0c 0012ffb8 004076f6 MSVBVM60!ThunRTMain+0xc5
0d 0012fff0 00000000 MyApp!__vbaS+0xa
There is another break after this, but I believe that is the normal "final
breakpoint" you were referring to below.
Do you see any clues in the above as to what is causing the breakpoints? Or
is there something I can do in WinDbg to determine definitively where the
error is coming from?
Thanks so much.
Marcia
"Prasad Kakulamarri [MSFT]" wrote:
> Marcia,
> You should look at the callstack and find out the reason for the break.
> AppVerifier
> issues a DbgBreak with a verifier stop message when it encounters an error
> in the
> application being verified. Since DbgBreak is in ntdll.dll, it appears that
> the break
> is in ntdll.
> In general do not ignore any breaks that the debugger hits...except the
> initial break point
> and the final break point if the process is exiting normally.
>
> Thanks,
> Prasad
>
> "Marcia" wrote:
>
> > Prasad,
> >
> > Thank you so much for your helpful response. I have another question: is
> > it safe to assume any breakpoint associated with nt.dll is a breakpoint
> > caused by the debugger and not something I need to worry about?
> >
> > "Prasad Kakulamarri [MSFT]" wrote:
> >
> > > Hi,
> > > The breakpoint you are seeing is the initial break point. When the debugger
> > > starts a new target application,
> > > an initial breakpoint automatically occurs after the main image and all
> > > statically-linked DLLs are loaded but
> > > before any DLL initialization routines are called.
> > > The -g command-line option causes WinDbg or CDB to ignore the initial
> > > breakpoint.
> > > Please search for "initial breakpoint" in debugger help index.
> > >
> > > Thanks,
> > > Prasad
> > >
> > >
> > > "Marcia" wrote:
> > >
> > > > Hello,
> > > >
> > > > Another first-time user of AppVerifier and WinDbg here --
> > > >
> > > > We are prepping our application for the VeriTest competency test and right
> > > > now have everything under "Basics" checked in AppVerifier. This is a VB6 app
> > > > that performs without error when run outside AppVerifier. We get no errors
> > > > when running under AppVerifier until we close the application, at which point
> > > > we get 2 Breakpoint exceptions. When run in WinDbg, we get several more
> > > > exceptions, some at the start of the app execution and some at the end. I
> > > > cannot determine at this point if this is an issue with our code or with VB6
> > > > (or something else altogether). I would like to start by showing you what
> > > > happens in WinDbg when the application opens. It appears we reach a
> > > > breakpoint even before all of the modules are loaded. Here it is:
> > > >
> > > > Closing open log file c:\MyAppdevelopment\MyApp\DebugLogs\20071121_1018.log
> > > > Opened log file 'c:\MyAppdevelopment\MyApp\debuglogs\log_1103.txt'
> > > >
> > > > Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
> > > > Copyright (c) Microsoft Corporation. All rights reserved.
> > > >
> > > > CommandLine: C:\MyAppdevelopment\MyApp\MyApp.exe
> > > > Symbol search path is:
> > > > SRV*c:\symbols*http://msdl.microsoft.com/download/symbols;symsrv*symsrv.dll*C:\symbols*http://msdl.microsoft.com/download/symbols
> > > > Executable search path is:
> > > > ModLoad: 00400000 004d5000 MyApp.exe
> > > > ModLoad: 7c900000 7c9b0000 ntdll.dll
> > > > AVRF: MyApp.exe: pid 0x1630: flags 0x80000181: application verifier enabled
> > > > ModLoad: 5ad10000 5ad56000 C:\WINDOWS\System32\verifier.dll
> > > > ModLoad: 00360000 00388000 C:\WINDOWS\System32\vrfcore.dll
> > > > ModLoad: 00390000 003c9000 C:\WINDOWS\System32\vfbasics.dll
> > > > ModLoad: 7c800000 7c8f5000 C:\WINDOWS\system32\kernel32.dll
> > > > AVRF: verifier.dll provider initialized for MyApp.exe with flags 0x80000181
> > > > ModLoad: 73420000 73574000 C:\WINDOWS\system32\MSVBVM60.DLL
> > > > ModLoad: 7e410000 7e4a0000 C:\WINDOWS\system32\USER32.dll
> > > > ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
> > > > ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.dll
> > > > ModLoad: 77e70000 77f01000 C:\WINDOWS\system32\RPCRT4.dll
> > > > ModLoad: 774e0000 7761d000 C:\WINDOWS\system32\ole32.dll
> > > > ModLoad: 77c10000 77c68000 C:\WINDOWS\system32\msvcrt.dll
> > > > ModLoad: 77120000 771ab000 C:\WINDOWS\system32\OLEAUT32.dll
> > > > (1630.1528): Break instruction exception - code 80000003 (first chance)
> > > > eax=014e6fec ebx=7ffdf000 ecx=00000001 edx=00000002 esi=014eafb0 edi=014e6fec
> > > > eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0 nv up ei pl nz na po nc
> > > > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
> > > > ntdll!DbgBreakPoint:
> > > > 7c901230 cc int 3
> > > >
> > > > When I hit "g", it loads the rest of the modules. Is the above a breakpoint
> > > > coming from ntdll, or is that simply the module that reports errors? I'm
> > > > sorry if this is a dumb question, but as a VB developer, you might imagine I
> > > > am quite lost looking at all of this "inside stuff" that I thought was being
> > > > handled by the runtime.
> > > >
> > > > Any insight would be most appreciated!
> > > > Thanks,
> > > > Marcia
date: Thu, 6 Dec 2007 14:14:01 -0800
author: Marcia
RE: AppVerifier breakpoint when closing VB6 application
Hi Marcia,
You can run !avrf debugger extension and follow the troubleshooting steps
outlines when you encounter a verifier stop.
!avrf depends on good symbols.
You can also find out the troubleshooting steps of a verifier stop from
appverifier help file
that ships with the package.
You are running into 2 issues here
1) A dll is being unloaded when it holds an active critical section,
verifier stop 0x201.
The third parameter to this verifier stop is a pointer to the dll name that
is being unloaded.
Run "du <third_param" at the debugger prompt to find out which dll is being
unloaded that holds
the critical section.
2) Invalid handle exception, verifier stop 0x300
run !htrace and look for BAD_REFERENCE in the stack traces that are dumped.
When
handle checks are enabled, Appverifier keeps track of open, close and any
bad references
on handles and saves stack traces for these operations. If a handle is being
used after
a close, it will cause an invalid handle exception and you can find the
stack trace for all
operations on this handle using !htrace.
If these are not in your modules and they are continuable stops, you can
ignore them and
continue testing your app.
Thanks,
Prasad
"Marcia" wrote:
> Thank you, Prasad. I wonder if I could trouble you a little more.
>
> I am getting 2 breakpoint exceptions from AppVerifier upon closing my
> application. I broke into them using WinDbg and got the error messages and
> the call stack. It appears to me that the break is perhaps coming from a
> module that is out of my control. I'm specifically suspicious of
> MSVBVM60.dll. Would you be so kind as to examine the following sequence of 2
> breakpoints and tell me if this is coming from my application?
>
> Here is break #1:
> (dd0.16c0): Break instruction exception - code 80000003 (!!! second chance
> !!!)
> eax=000001ff ebx=003a8844 ecx=7c91eb05 edx=000001c0 esi=00000000 edi=000001ff
> eip=7c901230 esp=0012f93c ebp=0012fb3c iopl=0 nv up ei pl nz na po nc
> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
> ntdll!DbgBreakPoint:
> 7c901230 cc int 3
>
> Call Stack:
>
> # ChildEBP RetAddr
> 00 0012f938 00363933 ntdll!DbgBreakPoint (FPO: [0,0,0])
> 01 0012fb3c 003a2fbe vrfcore!VerifierStopMessageEx+0x4bd (FPO: [Non-Fpo])
> (CONV: cdecl) [e:\verifier\source\base\avrf\avrf30\vrfcore\sdk.cpp @ 530]
> 02 0012fb60 003960cd vfbasics!VfBasicsStopMessage+0x8e (FPO: [Non-Fpo])
> (CONV: stdcall)
> [e:\verifier\source\base\avrf\avrf30\providers\basics\basics.c @ 1066]
> 03 0012fba8 00399d99 vfbasics!AVrfpFreeMemLockChecks+0x17d (FPO: [Non-Fpo])
> (CONV: stdcall)
> [e:\verifier\source\base\avrf\avrf30\providers\basics\critsect.c @ 1124]
> 04 0012fbc4 003a0d6c vfbasics!AVrfpFreeMemNotify+0x39 (FPO: [Non-Fpo])
> (CONV: stdcall)
> [e:\verifier\source\base\avrf\avrf30\providers\basics\support.c @ 1244]
> 05 0012fbf0 7c954a69 vfbasics!AVrfpDllUnloadCallback+0x2c (FPO: [Non-Fpo])
> (CONV: stdcall) [e:\verifier\source\base\avrf\avrf30\providers\basics\dlls.c
> @ 452]
> 06 0012fc14 7c93d4d4 ntdll!AVrfDllUnloadNotification+0x78 (FPO: [Non-Fpo])
> 07 0012fd00 003a1703 ntdll!LdrUnloadDll+0x2cd (FPO: [Non-Fpo])
> 08 0012fd18 7c80abf7 vfbasics!AVrfpLdrUnloadDll+0x73 (FPO: [Non-Fpo]) (CONV:
> stdcall) [e:\verifier\source\base\avrf\avrf30\providers\basics\dlls.c @ 1297]
> 09 0012fd2c 77513442 kernel32!FreeLibrary+0x3f (FPO: [Non-Fpo])
> 0a 0012fd38 77513456
> ole32!CClassCache::CDllPathEntry::CFinishObject::Finish+0x2f (FPO: [Non-Fpo])
> 0b 0012fd4c 77530729 ole32!CClassCache::CFinishComposite::Finish+0x1d (FPO:
> [0,0,0])
> 0c 0012fecc 7752fd6a ole32!CClassCache::CleanUpDllsForProcess+0x1b2 (FPO:
> [Non-Fpo])
> 0d 0012fed0 7752fee4 ole32!ProcessUninitialize+0x37 (FPO: [0,0,0])
> 0e 0012fee4 774fee88 ole32!wCoUninitialize+0x11b (FPO: [Non-Fpo])
> 0f 0012ff00 734397bf ole32!CoUninitialize+0x5b (FPO: [Non-Fpo])
> 10 0012ff0c 73439712 MSVBVM60!InitTermGlobal+0xaa (FPO: [0,0,2])
> 11 0012ff1c 7343718b MSVBVM60!CThreadPool::TerminateRuntime+0x21
> 12 0012ff34 7343ba15 MSVBVM60!CVBThreadAction::Stop+0xb0 (FPO: [Uses EBP]
> [0,1,4])
> 13 0012ff40 7342dee0 MSVBVM60!CThreadPool::TerminateThread+0x43 (FPO: [0,0,2])
> 14 0012ffb8 004076f6 MSVBVM60!ThunRTMain+0xb9
> 15 0012fff0 00000000 MyApp!__vbaS+0xa
>
> When I hit "Go", I get another break:
> (dd0.16c0): Invalid handle - code c0000008 (first chance)
>
>
> =======================================
> VERIFIER STOP 00000300 : pid 0xDD0: Invalid handle exception for current
> stack trace.
>
> C0000008 : Exception code.
> 0012FAD0 : Exception record. Use .exr to display it.
> 0012FAE4 : Context record. Use .cxr to display it.
> 00000000 : Not used.
>
>
> =======================================
> This verifier stop is continuable.
> After debugging it use `go' to continue.
>
> =======================================
>
> (dd0.16c0): Break instruction exception - code 80000003 (first chance)
> eax=000001ff ebx=003a8d08 ecx=7c91eb05 edx=0012f739 esi=00000000 edi=000001ff
> eip=7c901230 esp=0012f7c8 ebp=0012f9c8 iopl=0 nv up ei pl nz na po nc
> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
> ntdll!DbgBreakPoint:
> 7c901230 cc int 3
>
> Call Stack
> # ChildEBP RetAddr
> 00 0012f7c4 00363933 ntdll!DbgBreakPoint (FPO: [0,0,0])
> 01 0012f9c8 003a3001 vrfcore!VerifierStopMessageEx+0x4bd (FPO: [Non-Fpo])
> (CONV: cdecl) [e:\verifier\source\base\avrf\avrf30\vrfcore\sdk.cpp @ 530]
> 02 0012f9ec 00398f5b vfbasics!VfBasicsStopMessage+0xd1 (FPO: [Non-Fpo])
> (CONV: stdcall)
> [e:\verifier\source\base\avrf\avrf30\providers\basics\basics.c @ 1071]
> 03 0012fa20 7c942dcf vfbasics!AVrfpVectoredExceptionHandler+0x9b (FPO:
> [Non-Fpo]) (CONV: stdcall)
> [e:\verifier\source\base\avrf\avrf30\providers\basics\support.c @ 243]
> 04 0012fa40 7c9377da ntdll!RtlCallVectoredExceptionHandlers+0x48 (FPO:
> [Non-Fpo])
> 05 0012fab8 7c90eafa ntdll!RtlDispatchException+0x19 (FPO: [Non-Fpo])
> 06 0012fab8 7c90eb74 ntdll!KiUserExceptionDispatcher+0xe (FPO: [2,0,0])
> (CONTEXT @ 0012fae4)
> 07 0012fe00 7c90eb93 ntdll!KiRaiseUserExceptionDispatcher+0x37
> 08 0012fe1c 7c81cd6b ntdll!KiFastSystemCallRet+0x4
> 09 0012ff18 7c81cdee kernel32!_ExitProcess+0x37 (FPO: [Non-Fpo])
> 0a 0012ff2c 00394e6a kernel32!ExitProcess+0x14
> 0b 0012ff3c 7342deec vfbasics!AVrfpExitProcess+0x3a (FPO: [Non-Fpo]) (CONV:
> stdcall) [e:\verifier\source\base\avrf\avrf30\providers\basics\thread.c @ 205]
> 0c 0012ffb8 004076f6 MSVBVM60!ThunRTMain+0xc5
> 0d 0012fff0 00000000 MyApp!__vbaS+0xa
>
> There is another break after this, but I believe that is the normal "final
> breakpoint" you were referring to below.
>
> Do you see any clues in the above as to what is causing the breakpoints? Or
> is there something I can do in WinDbg to determine definitively where the
> error is coming from?
>
> Thanks so much.
> Marcia
>
> "Prasad Kakulamarri [MSFT]" wrote:
>
> > Marcia,
> > You should look at the callstack and find out the reason for the break.
> > AppVerifier
> > issues a DbgBreak with a verifier stop message when it encounters an error
> > in the
> > application being verified. Since DbgBreak is in ntdll.dll, it appears that
> > the break
> > is in ntdll.
> > In general do not ignore any breaks that the debugger hits...except the
> > initial break point
> > and the final break point if the process is exiting normally.
> >
> > Thanks,
> > Prasad
> >
> > "Marcia" wrote:
> >
> > > Prasad,
> > >
> > > Thank you so much for your helpful response. I have another question: is
> > > it safe to assume any breakpoint associated with nt.dll is a breakpoint
> > > caused by the debugger and not something I need to worry about?
> > >
> > > "Prasad Kakulamarri [MSFT]" wrote:
> > >
> > > > Hi,
> > > > The breakpoint you are seeing is the initial break point. When the debugger
> > > > starts a new target application,
> > > > an initial breakpoint automatically occurs after the main image and all
> > > > statically-linked DLLs are loaded but
> > > > before any DLL initialization routines are called.
> > > > The -g command-line option causes WinDbg or CDB to ignore the initial
> > > > breakpoint.
> > > > Please search for "initial breakpoint" in debugger help index.
> > > >
> > > > Thanks,
> > > > Prasad
> > > >
> > > >
> > > > "Marcia" wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > Another first-time user of AppVerifier and WinDbg here --
> > > > >
> > > > > We are prepping our application for the VeriTest competency test and right
> > > > > now have everything under "Basics" checked in AppVerifier. This is a VB6 app
> > > > > that performs without error when run outside AppVerifier. We get no errors
> > > > > when running under AppVerifier until we close the application, at which point
> > > > > we get 2 Breakpoint exceptions. When run in WinDbg, we get several more
> > > > > exceptions, some at the start of the app execution and some at the end. I
> > > > > cannot determine at this point if this is an issue with our code or with VB6
> > > > > (or something else altogether). I would like to start by showing you what
> > > > > happens in WinDbg when the application opens. It appears we reach a
> > > > > breakpoint even before all of the modules are loaded. Here it is:
> > > > >
> > > > > Closing open log file c:\MyAppdevelopment\MyApp\DebugLogs\20071121_1018.log
> > > > > Opened log file 'c:\MyAppdevelopment\MyApp\debuglogs\log_1103.txt'
> > > > >
> > > > > Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
> > > > > Copyright (c) Microsoft Corporation. All rights reserved.
> > > > >
> > > > > CommandLine: C:\MyAppdevelopment\MyApp\MyApp.exe
> > > > > Symbol search path is:
> > > > > SRV*c:\symbols*http://msdl.microsoft.com/download/symbols;symsrv*symsrv.dll*C:\symbols*http://msdl.microsoft.com/download/symbols
> > > > > Executable search path is:
> > > > > ModLoad: 00400000 004d5000 MyApp.exe
> > > > > ModLoad: 7c900000 7c9b0000 ntdll.dll
> > > > > AVRF: MyApp.exe: pid 0x1630: flags 0x80000181: application verifier enabled
> > > > > ModLoad: 5ad10000 5ad56000 C:\WINDOWS\System32\verifier.dll
> > > > > ModLoad: 00360000 00388000 C:\WINDOWS\System32\vrfcore.dll
> > > > > ModLoad: 00390000 003c9000 C:\WINDOWS\System32\vfbasics.dll
> > > > > ModLoad: 7c800000 7c8f5000 C:\WINDOWS\system32\kernel32.dll
> > > > > AVRF: verifier.dll provider initialized for MyApp.exe with flags 0x80000181
> > > > > ModLoad: 73420000 73574000 C:\WINDOWS\system32\MSVBVM60.DLL
> > > > > ModLoad: 7e410000 7e4a0000 C:\WINDOWS\system32\USER32.dll
> > > > > ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
> > > > > ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.dll
> > > > > ModLoad: 77e70000 77f01000 C:\WINDOWS\system32\RPCRT4.dll
> > > > > ModLoad: 774e0000 7761d000 C:\WINDOWS\system32\ole32.dll
> > > > > ModLoad: 77c10000 77c68000 C:\WINDOWS\system32\msvcrt.dll
> > > > > ModLoad: 77120000 771ab000 C:\WINDOWS\system32\OLEAUT32.dll
> > > > > (1630.1528): Break instruction exception - code 80000003 (first chance)
> > > > > eax=014e6fec ebx=7ffdf000 ecx=00000001 edx=00000002 esi=014eafb0 edi=014e6fec
> > > > > eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0 nv up ei pl nz na po nc
> > > > > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
> > > > > ntdll!DbgBreakPoint:
> > > > > 7c901230 cc int 3
> > > > >
> > > > > When I hit "g", it loads the rest of the modules. Is the above a breakpoint
> > > > > coming from ntdll, or is that simply the module that reports errors? I'm
> > > > > sorry if this is a dumb question, but as a VB developer, you might imagine I
> > > > > am quite lost looking at all of this "inside stuff" that I thought was being
> > > > > handled by the runtime.
> > > > >
> > > > > Any insight would be most appreciated!
> > > > > Thanks,
> > > > > Marcia
date: Fri, 7 Dec 2007 16:04:01 -0800
author: Prasad Kakulamarri [MSFT]
RE: AppVerifier breakpoint when closing VB6 application
Prasad,
Thank you so much for taking the time to explain the debugging steps to me.
I really appreciate your help!
Thanks,
Marcia
"Prasad Kakulamarri [MSFT]" wrote:
>
> Hi Marcia,
> You can run !avrf debugger extension and follow the troubleshooting steps
> outlines when you encounter a verifier stop.
> !avrf depends on good symbols.
> You can also find out the troubleshooting steps of a verifier stop from
> appverifier help file
> that ships with the package.
> You are running into 2 issues here
> 1) A dll is being unloaded when it holds an active critical section,
> verifier stop 0x201.
> The third parameter to this verifier stop is a pointer to the dll name that
> is being unloaded.
> Run "du <third_param" at the debugger prompt to find out which dll is being
> unloaded that holds
> the critical section.
>
> 2) Invalid handle exception, verifier stop 0x300
> run !htrace and look for BAD_REFERENCE in the stack traces that are dumped.
> When
> handle checks are enabled, Appverifier keeps track of open, close and any
> bad references
> on handles and saves stack traces for these operations. If a handle is being
> used after
> a close, it will cause an invalid handle exception and you can find the
> stack trace for all
> operations on this handle using !htrace.
>
> If these are not in your modules and they are continuable stops, you can
> ignore them and
> continue testing your app.
>
> Thanks,
> Prasad
>
> "Marcia" wrote:
>
> > Thank you, Prasad. I wonder if I could trouble you a little more.
> >
> > I am getting 2 breakpoint exceptions from AppVerifier upon closing my
> > application. I broke into them using WinDbg and got the error messages and
> > the call stack. It appears to me that the break is perhaps coming from a
> > module that is out of my control. I'm specifically suspicious of
> > MSVBVM60.dll. Would you be so kind as to examine the following sequence of 2
> > breakpoints and tell me if this is coming from my application?
> >
> > Here is break #1:
> > (dd0.16c0): Break instruction exception - code 80000003 (!!! second chance
> > !!!)
> > eax=000001ff ebx=003a8844 ecx=7c91eb05 edx=000001c0 esi=00000000 edi=000001ff
> > eip=7c901230 esp=0012f93c ebp=0012fb3c iopl=0 nv up ei pl nz na po nc
> > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
> > ntdll!DbgBreakPoint:
> > 7c901230 cc int 3
> >
> > Call Stack:
> >
> > # ChildEBP RetAddr
> > 00 0012f938 00363933 ntdll!DbgBreakPoint (FPO: [0,0,0])
> > 01 0012fb3c 003a2fbe vrfcore!VerifierStopMessageEx+0x4bd (FPO: [Non-Fpo])
> > (CONV: cdecl) [e:\verifier\source\base\avrf\avrf30\vrfcore\sdk.cpp @ 530]
> > 02 0012fb60 003960cd vfbasics!VfBasicsStopMessage+0x8e (FPO: [Non-Fpo])
> > (CONV: stdcall)
> > [e:\verifier\source\base\avrf\avrf30\providers\basics\basics.c @ 1066]
> > 03 0012fba8 00399d99 vfbasics!AVrfpFreeMemLockChecks+0x17d (FPO: [Non-Fpo])
> > (CONV: stdcall)
> > [e:\verifier\source\base\avrf\avrf30\providers\basics\critsect.c @ 1124]
> > 04 0012fbc4 003a0d6c vfbasics!AVrfpFreeMemNotify+0x39 (FPO: [Non-Fpo])
> > (CONV: stdcall)
> > [e:\verifier\source\base\avrf\avrf30\providers\basics\support.c @ 1244]
> > 05 0012fbf0 7c954a69 vfbasics!AVrfpDllUnloadCallback+0x2c (FPO: [Non-Fpo])
> > (CONV: stdcall) [e:\verifier\source\base\avrf\avrf30\providers\basics\dlls.c
> > @ 452]
> > 06 0012fc14 7c93d4d4 ntdll!AVrfDllUnloadNotification+0x78 (FPO: [Non-Fpo])
> > 07 0012fd00 003a1703 ntdll!LdrUnloadDll+0x2cd (FPO: [Non-Fpo])
> > 08 0012fd18 7c80abf7 vfbasics!AVrfpLdrUnloadDll+0x73 (FPO: [Non-Fpo]) (CONV:
> > stdcall) [e:\verifier\source\base\avrf\avrf30\providers\basics\dlls.c @ 1297]
> > 09 0012fd2c 77513442 kernel32!FreeLibrary+0x3f (FPO: [Non-Fpo])
> > 0a 0012fd38 77513456
> > ole32!CClassCache::CDllPathEntry::CFinishObject::Finish+0x2f (FPO: [Non-Fpo])
> > 0b 0012fd4c 77530729 ole32!CClassCache::CFinishComposite::Finish+0x1d (FPO:
> > [0,0,0])
> > 0c 0012fecc 7752fd6a ole32!CClassCache::CleanUpDllsForProcess+0x1b2 (FPO:
> > [Non-Fpo])
> > 0d 0012fed0 7752fee4 ole32!ProcessUninitialize+0x37 (FPO: [0,0,0])
> > 0e 0012fee4 774fee88 ole32!wCoUninitialize+0x11b (FPO: [Non-Fpo])
> > 0f 0012ff00 734397bf ole32!CoUninitialize+0x5b (FPO: [Non-Fpo])
> > 10 0012ff0c 73439712 MSVBVM60!InitTermGlobal+0xaa (FPO: [0,0,2])
> > 11 0012ff1c 7343718b MSVBVM60!CThreadPool::TerminateRuntime+0x21
> > 12 0012ff34 7343ba15 MSVBVM60!CVBThreadAction::Stop+0xb0 (FPO: [Uses EBP]
> > [0,1,4])
> > 13 0012ff40 7342dee0 MSVBVM60!CThreadPool::TerminateThread+0x43 (FPO: [0,0,2])
> > 14 0012ffb8 004076f6 MSVBVM60!ThunRTMain+0xb9
> > 15 0012fff0 00000000 MyApp!__vbaS+0xa
> >
> > When I hit "Go", I get another break:
> > (dd0.16c0): Invalid handle - code c0000008 (first chance)
> >
> >
> > =======================================
> > VERIFIER STOP 00000300 : pid 0xDD0: Invalid handle exception for current
> > stack trace.
> >
> > C0000008 : Exception code.
> > 0012FAD0 : Exception record. Use .exr to display it.
> > 0012FAE4 : Context record. Use .cxr to display it.
> > 00000000 : Not used.
> >
> >
> > =======================================
> > This verifier stop is continuable.
> > After debugging it use `go' to continue.
> >
> > =======================================
> >
> > (dd0.16c0): Break instruction exception - code 80000003 (first chance)
> > eax=000001ff ebx=003a8d08 ecx=7c91eb05 edx=0012f739 esi=00000000 edi=000001ff
> > eip=7c901230 esp=0012f7c8 ebp=0012f9c8 iopl=0 nv up ei pl nz na po nc
> > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
> > ntdll!DbgBreakPoint:
> > 7c901230 cc int 3
> >
> > Call Stack
> > # ChildEBP RetAddr
> > 00 0012f7c4 00363933 ntdll!DbgBreakPoint (FPO: [0,0,0])
> > 01 0012f9c8 003a3001 vrfcore!VerifierStopMessageEx+0x4bd (FPO: [Non-Fpo])
> > (CONV: cdecl) [e:\verifier\source\base\avrf\avrf30\vrfcore\sdk.cpp @ 530]
> > 02 0012f9ec 00398f5b vfbasics!VfBasicsStopMessage+0xd1 (FPO: [Non-Fpo])
> > (CONV: stdcall)
> > [e:\verifier\source\base\avrf\avrf30\providers\basics\basics.c @ 1071]
> > 03 0012fa20 7c942dcf vfbasics!AVrfpVectoredExceptionHandler+0x9b (FPO:
> > [Non-Fpo]) (CONV: stdcall)
> > [e:\verifier\source\base\avrf\avrf30\providers\basics\support.c @ 243]
> > 04 0012fa40 7c9377da ntdll!RtlCallVectoredExceptionHandlers+0x48 (FPO:
> > [Non-Fpo])
> > 05 0012fab8 7c90eafa ntdll!RtlDispatchException+0x19 (FPO: [Non-Fpo])
> > 06 0012fab8 7c90eb74 ntdll!KiUserExceptionDispatcher+0xe (FPO: [2,0,0])
> > (CONTEXT @ 0012fae4)
> > 07 0012fe00 7c90eb93 ntdll!KiRaiseUserExceptionDispatcher+0x37
> > 08 0012fe1c 7c81cd6b ntdll!KiFastSystemCallRet+0x4
> > 09 0012ff18 7c81cdee kernel32!_ExitProcess+0x37 (FPO: [Non-Fpo])
> > 0a 0012ff2c 00394e6a kernel32!ExitProcess+0x14
> > 0b 0012ff3c 7342deec vfbasics!AVrfpExitProcess+0x3a (FPO: [Non-Fpo]) (CONV:
> > stdcall) [e:\verifier\source\base\avrf\avrf30\providers\basics\thread.c @ 205]
> > 0c 0012ffb8 004076f6 MSVBVM60!ThunRTMain+0xc5
> > 0d 0012fff0 00000000 MyApp!__vbaS+0xa
> >
> > There is another break after this, but I believe that is the normal "final
> > breakpoint" you were referring to below.
> >
> > Do you see any clues in the above as to what is causing the breakpoints? Or
> > is there something I can do in WinDbg to determine definitively where the
> > error is coming from?
> >
> > Thanks so much.
> > Marcia
> >
> > "Prasad Kakulamarri [MSFT]" wrote:
> >
> > > Marcia,
> > > You should look at the callstack and find out the reason for the break.
> > > AppVerifier
> > > issues a DbgBreak with a verifier stop message when it encounters an error
> > > in the
> > > application being verified. Since DbgBreak is in ntdll.dll, it appears that
> > > the break
> > > is in ntdll.
> > > In general do not ignore any breaks that the debugger hits...except the
> > > initial break point
> > > and the final break point if the process is exiting normally.
> > >
> > > Thanks,
> > > Prasad
> > >
> > > "Marcia" wrote:
> > >
> > > > Prasad,
> > > >
> > > > Thank you so much for your helpful response. I have another question: is
> > > > it safe to assume any breakpoint associated with nt.dll is a breakpoint
> > > > caused by the debugger and not something I need to worry about?
> > > >
> > > > "Prasad Kakulamarri [MSFT]" wrote:
> > > >
> > > > > Hi,
> > > > > The breakpoint you are seeing is the initial break point. When the debugger
> > > > > starts a new target application,
> > > > > an initial breakpoint automatically occurs after the main image and all
> > > > > statically-linked DLLs are loaded but
> > > > > before any DLL initialization routines are called.
> > > > > The -g command-line option causes WinDbg or CDB to ignore the initial
> > > > > breakpoint.
> > > > > Please search for "initial breakpoint" in debugger help index.
> > > > >
> > > > > Thanks,
> > > > > Prasad
> > > > >
> > > > >
> > > > > "Marcia" wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > Another first-time user of AppVerifier and WinDbg here --
> > > > > >
> > > > > > We are prepping our application for the VeriTest competency test and right
> > > > > > now have everything under "Basics" checked in AppVerifier. This is a VB6 app
> > > > > > that performs without error when run outside AppVerifier. We get no errors
> > > > > > when running under AppVerifier until we close the application, at which point
> > > > > > we get 2 Breakpoint exceptions. When run in WinDbg, we get several more
> > > > > > exceptions, some at the start of the app execution and some at the end. I
> > > > > > cannot determine at this point if this is an issue with our code or with VB6
> > > > > > (or something else altogether). I would like to start by showing you what
> > > > > > happens in WinDbg when the application opens. It appears we reach a
> > > > > > breakpoint even before all of the modules are loaded. Here it is:
> > > > > >
> > > > > > Closing open log file c:\MyAppdevelopment\MyApp\DebugLogs\20071121_1018.log
> > > > > > Opened log file 'c:\MyAppdevelopment\MyApp\debuglogs\log_1103.txt'
> > > > > >
> > > > > > Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
> > > > > > Copyright (c) Microsoft Corporation. All rights reserved.
> > > > > >
> > > > > > CommandLine: C:\MyAppdevelopment\MyApp\MyApp.exe
> > > > > > Symbol search path is:
> > > > > > SRV*c:\symbols*http://msdl.microsoft.com/download/symbols;symsrv*symsrv.dll*C:\symbols*http://msdl.microsoft.com/download/symbols
> > > > > > Executable search path is:
> > > > > > ModLoad: 00400000 004d5000 MyApp.exe
> > > > > > ModLoad: 7c900000 7c9b0000 ntdll.dll
> > > > > > AVRF: MyApp.exe: pid 0x1630: flags 0x80000181: application verifier enabled
> > > > > > ModLoad: 5ad10000 5ad56000 C:\WINDOWS\System32\verifier.dll
> > > > > > ModLoad: 00360000 00388000 C:\WINDOWS\System32\vrfcore.dll
> > > > > > ModLoad: 00390000 003c9000 C:\WINDOWS\System32\vfbasics.dll
> > > > > > ModLoad: 7c800000 7c8f5000 C:\WINDOWS\system32\kernel32.dll
> > > > > > AVRF: verifier.dll provider initialized for MyApp.exe with flags 0x80000181
> > > > > > ModLoad: 73420000 73574000 C:\WINDOWS\system32\MSVBVM60.DLL
> > > > > > ModLoad: 7e410000 7e4a0000 C:\WINDOWS\system32\USER32.dll
> > > > > > ModLoad: 77f10000 77f57000 C:\WINDOWS\system32\GDI32.dll
> > > > > > ModLoad: 77dd0000 77e6b000 C:\WINDOWS\system32\ADVAPI32.dll
> > > > > > ModLoad: 77e70000 77f01000 C:\WINDOWS\system32\RPCRT4.dll
> > > > > > ModLoad: 774e0000 7761d000 C:\WINDOWS\system32\ole32.dll
> > > > > > ModLoad: 77c10000 77c68000 C:\WINDOWS\system32\msvcrt.dll
> > > > > > ModLoad: 77120000 771ab000 C:\WINDOWS\system32\OLEAUT32.dll
> > > > > > (1630.1528): Break instruction exception - code 80000003 (first chance)
> > > > > > eax=014e6fec ebx=7ffdf000 ecx=00000001 edx=00000002 esi=014eafb0 edi=014e6fec
> > > > > > eip=7c901230 esp=0012fb20 ebp=0012fc94 iopl=0 nv up ei pl nz na po nc
> > > > > > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
> > > > > > ntdll!DbgBreakPoint:
> > > > > > 7c901230 cc int 3
> > > > > >
> > > > > > When I hit "g", it loads the rest of the modules. Is the above a breakpoint
> > > > > > coming from ntdll, or is that simply the module that reports errors? I'm
> > > > > > sorry if this is a dumb question, but as a VB developer, you might imagine I
> > > > > > am quite lost looking at all of this "inside stuff" that I thought was being
> > > > > > handled by the runtime.
> > > > > >
> > > > > > Any insight would be most appreciated!
> > > > > > Thanks,
> > > > > > Marcia
date: Tue, 11 Dec 2007 07:30:01 -0800
author: Marcia
|
|
