Is this a non existing handle to WaitForSingleObject
Kjell Gunnar
Report (8.0)
Occasionally the APP hags forever and I have investigated some dumps,
and a live hang.
They all looks like this: (see below)
I wonder why thread be4 (main thread) is waiting for 2f0.
Q1: Does the !handle output indicate that this is not a valid hande ?
(when doing !handle <cr> it does not output any 2f0 handle)
Q2: If the handle is invalid, shouldn't WaitForSingleObject return
immediately with An error ?
Q3: Can I find out anything else ? (from ether a dump or a live )
If not I will conclude that this is an error in a rather old Crystal
Reports component, and hunt for a newer version.
Info: mcrpe32 is Seagate Crystal Reports Print Engine
Thanks
Kjell Gunnar.
:000> ~*kv
. 0 Id: 159c.be4 Suspend: 1 Teb: 7ffdd000 Unfrozen
ChildEBP RetAddr Args to Child
0012e6a4 7c90e9c0 7c8025db 000002f0 00000000 ntdll!KiFastSystemCallRet
(FPO: [0,0,0])
0012e6a8 7c8025db 000002f0 00000000 00000000
ntdll!ZwWaitForSingleObject+0xc (FPO: [3,0,0])
0012e70c 7c802542 000002f0 ffffffff 00000000
kernel32!WaitForSingleObjectEx+0xa8 (FPO: [Non-Fpo])
0012e720 402be647 000002f0 ffffffff 7c802442
kernel32!WaitForSingleObject+0x12 (FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may
be wrong.
00000000 00000000 00000000 00000000 00000000
crpe32!DeleteUFLString+0x18add7
1 Id: 159c.116c Suspend: 1 Teb: 7ffdc000 Unfrozen
ChildEBP RetAddr Args to Child
0390fe94 77d4919b 77d6ea85 00183858 00000000 ntdll!KiFastSystemCallRet
(FPO: [0,0,0])
0390febc 7c14f390 00183858 00000000 00000000
user32!NtUserGetMessage+0xc
0390fed8 7c165bbc 0012e508 0187ba50 0390ff00
mfc70!AfxInternalPumpMessage+0x18 (FPO: [0,0,2])
0390fef4 0308348f 0187ba50 0390ff80 7c17b24b mfc70!CWinThread::Run+0x54
(FPO: [EBP 0x0390ff00] [0,2,4])
0390ff00 7c17b24b 00000010 0187bb58 0187c3f0
<MyApp>!<MyApp>Thread::Run+0x19 (FPO: [Non-Fpo]) (CONV: thiscall)
[d:\make_osk\2.1.1.24\dev\package\hg42_servercontainer\baseserver\oskservthread.cpp
@ 178]
0390ff80 7c00412f 0012e508 00000010 0012e3ec
mfc70!_AfxThreadEntry+0x100 (FPO: [Non-Fpo])
0390ffb4 7c80b50b 0187c3f0 00000010 0012e3ec msvcr70!_endthreadex+0xa0
(FPO: [Non-Fpo])
0390ffec 00000000 7c0040e2 0187c3f0 00000000
kernel32!BaseThreadStart+0x37 (FPO: [Non-Fpo])
2 Id: 159c.1f08 Suspend: 1 Teb: 7ffdb000 Unfrozen
ChildEBP RetAddr Args to Child
0415ff78 7c90e31b 71a5d609 000002d0 0415ffbc ntdll!KiFastSystemCallRet
(FPO: [0,0,0])
0415ff7c 71a5d609 000002d0 0415ffbc 0415ffb0
ntdll!ZwRemoveIoCompletion+0xc (FPO: [5,0,0])
0415ffb4 7c80b50b 71a67a25 0390f5f0 7c90ee18
mswsock!SockAsyncThread+0x5a (FPO: [Non-Fpo])
0415ffec 00000000 71a5d5af 001978e0 00000000
kernel32!BaseThreadStart+0x37 (FPO: [Non-Fpo])
# 3 Id: 159c.1b80 Suspend: 1 Teb: 7ffda000 Unfrozen
ChildEBP RetAddr Args to Child
03d8ffc8 7c9507a8 00000005 00000004 00000001 ntdll!DbgBreakPoint (FPO:
[0,0,0])
03d8fff4 00000000 00000000 00000000 00000000
ntdll!DbgUiRemoteBreakin+0x2d (FPO: [Non-Fpo])
0:000> !handle 0x2f0 f
Handle 000002f0
Type <Error retrieving type>
unable to query object information
unable to query object information
No object specific information available
0:000> !locks
CritSec crpe32!Prompt3DViewAnglePresetDialog+10e1a8 at 40430D98
LockCount 0
RecursionCount 1
OwningThread be4
EntryCount 0
ContentionCount 0
*** Locked
0:000> lmv mcrpe32
start end module name
40000000 40520000 crpe32 (export symbols) crpe32.dll
Loaded symbol image file: crpe32.dll
Image path: C:\WINDOWS\system32\crpe32.dll
Image name: crpe32.dll
Timestamp: Sat Jan 29 00:16:43 2000 (3892235B)
CheckSum: 005222F6
ImageSize: 00520000
File version: 8.0.0.371
Product version: 8.0.1.0
File flags: 8 (Mask 3F) Private
File OS: 4 Unknown Win32
File type: 1.0 App
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Seagate Software, Inc.
ProductName: Seagate Crystal Reports
InternalName: CRPE
OriginalFilename: CRPE32.DLL
ProductVersion: 8.0.1.0
FileVersion: 8.0.0.371
PrivateBuild: 333
FileDescription: Seagate Crystal Reports Print Engine
LegalCopyright: Copyright (c) 1991-1998 Seagate Software, Inc.
All rights reserved.
Comments: Seagate Crystal Reports
Pavel Lebedinsky [MSFT]
> I'm debugging an (MFC) app which displays reports using Crystall
> Report (8.0)
> Occasionally the APP hags forever and I have investigated some dumps,
> and a live hang.
>
> They all looks like this: (see below)
> I wonder why thread be4 (main thread) is waiting for 2f0.
>
> Q1: Does the !handle output indicate that this is not a valid hande ?
> (when doing !handle <cr> it does not output any 2f0 handle)
>
> Q2: If the handle is invalid, shouldn't WaitForSingleObject return
> immediately with An error ?
Yes, but if the handle is closed after the wait begins then the handle
becomes invalid but the wait will not return (and the actual kernel
object will not be destroyed because it would still have a non-zero
pointer count).
I'm not sure if this is really what's happening in your case, because
when I tried the above scenario I got a different error from !handle:
0:001> kb
ChildEBP RetAddr Args to Child
0050ff28 7c90e9c0 7c8025db 000007e8 00000000 ntdll!KiFastSystemCallRet
0050ff2c 7c8025db 000007e8 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc
0050ff90 7c802542 000007e8 ffffffff 00000000
kernel32!WaitForSingleObjectEx+0xa8
*** WARNING: Unable to verify checksum for test.exe
0050ffa4 00405c0f 000007e8 ffffffff 0050ffec
kernel32!WaitForSingleObject+0x12
0050ffb4 7c80b50b 000007e8 ffffffff 0012fbc4 test!ThreadFunc+0xf
0050ffec 00000000 0040100a 000007e8 00000000 kernel32!BaseThreadStart+0x37
0:001> !handle 000007e8
Could not duplicate handle 7e8, error 6
What debugger version are you using?
> Q3: Can I find out anything else ? (from ether a dump or a live )
> If not I will conclude that this is an error in a rather old Crystal
> Reports component, and hunt for a newer version.
You can enable handle checks in app verifier and try to reproduce
the problem. If it repros, use !htrace to dump stack traces associated
with the handle.
To enable handle checks, do this:
c:\debuggers> gflags -v image /enable my_app.exe HANDLE_CHECKS
Kjell Gunnar
As I understand it, another thread must have closed the handle after
159c.be4 thread entered wait state.
I'm using the (to my knowledge) latest Windbg.
dbgeng: image 6.4.0007.2, built Fri Jan 14 22:36:58 2005
On a live hang, I get similar output as you got.
The !handle output in my previous post was from a dump session.
I played a bit with gflags -v .... HANDLE_CHECKS
and !htrace on a test program during the weekend, it looked promising.
I applied it on the lab this morning on the real problem program,
finding that it refused to start at all.
Examine it in WinDbg showed Invalid TLS index (see below)
I doubt that this error has something to do with the original problem,
and it prevents me hitting the hang with HANDLE_CHECKS because
I have to run it several several ..... times.
Q1: I have not enabled TLS_CHECKS, so why does it stops ?
Q2: Is it a way to avoid the TLS break ?
========== Output ======
VERIFIER STOP 00000300: pid 0x11FC: Invalid TLS index used in current
stack (use kb).
FFFFFFFF : Invalid TLS index
0000ABBA : Expected lower part of the index
00000000 : (null)
00000000 : (null)
===========================================================
0:000> kv
ChildEBP RetAddr Args to Child
0012f5c0 7c9551ad 7c809750 ffffffff 40436440 ntdll!DbgBreakPoint (FPO:
[0,0,0])
0012f5d8 5ad12740 00000300 5ad1180c ffffffff
ntdll!RtlApplicationVerifierStop+0x160 (FPO: [Non-Fpo])
0012f604 5ad1278f ffffffff 00000000 01faa268
verifier!CheckTlsIndex+0x3d (FPO: [1,0,0])
0012f614 40064439 ffffffff 7c80aa97 01faa268
verifier!AVrfpTlsGetValue+0x1b (FPO: [1,0,2])
WARNING: Stack unwind information not available. Following frames may
be wrong.
0012f62c 40378e6b ffffffff 40312d17 00000000
CRPE32!PEGetFormulaTemplateKeywords+0xa49
0012f65c 403a614f ffffffff 40313096 0012f690
CRPE32!Prompt3DViewAnglePresetDialog+0x5627b
0012f67c 403a61e8 ffffffff 403320f8 00003982
CRPE32!Prompt3DViewAnglePresetDialog+0x8355f
0012f6c0 403a93da 00000008 4034068c 01fa8cf8
CRPE32!Prompt3DViewAnglePresetDialog+0x835f8
0012f91c 403a937e 00000004 40340aba 4043653c
CRPE32!Prompt3DViewAnglePresetDialog+0x867ea
0012f954 403a9418 00000002 4032e698 4043653c
CRPE32!Prompt3DViewAnglePresetDialog+0x8678e
0012f97c 403a8268 00000000 4006405a 01fa8c08
CRPE32!Prompt3DViewAnglePresetDialog+0x86828
0012f9ac 40378dd0 00000001 40374085 0012fd30
CRPE32!Prompt3DViewAnglePresetDialog+0x85678
0012fb08 7c90ee17 7c91ca50 00000002 0012fc94
CRPE32!Prompt3DViewAnglePresetDialog+0x561e0
0012fd0c 7c90ee17 7c918e00 00000001 00000000 ntdll!_SEH_epilog+0x15
ffffffff 00000000 00000000 00000000 00000000 ntdll!_SEH_epilog+0x15
0:000> !tls -1 0
TLS slots on thread: 11fc.ba0
0x0000 : 00000000
0x0001 : 01e81eb0
0x0002 : 01fa1eb0
0x0003 : 00000000
0x0004 : 00000000
0x0005 : 00000000
0x0006 : 00000000
0x0007 : 0025adf0
0x0008 : 00000000
0x0009 : 00000000
0x000a : 02169810
0x000b : 00000000
0x000c : 025e1eb0
0x000d : 00000000
0x000e : 00000000
0x000f : 00000000
0x0010 : 00000000
0x0011 : 02831eb0
0x0012 : 00000000
0x0013 : 00000000
0x0014 : 0029f9c0
Mike
One way that I have tracked these problems down before is to hook all of the
loaded dll's CloseHandle() calls. The hook calls the real CloseHandle()
function and if the close handle failed, would trace the call stack of the
offending handle close. This relies on the fact that in some cases the
handle will not have been re-used before the extra CloseHandle() call. In
this case, CloseHandle() will return false. This should help you track down
the places where CloseHandle() is being called too many times.
Pavel Lebedinsky [MSFT]
regardless of the actual verifier flags. If possible, you should fix
the code that causes these breaks. If you don't control this code
you should be able to continue past the break, or if the breaks
are happening repeatedly, you can disassemble verifier!CheckTlsIndex
and NOP out the call to verifier!RtlApplicationVerifierStop.
--
This posting is provided "AS IS" with no warranties, and confers no
rights.
Kjell Gunnar
Thank you a lot, I did several runs with
bp kernel32!CloseHandle "gu; j (@eax != 0) 'gc';'kv'"
To catch a call to CloseHandle with illegal handle, but none
observed.
I was not able to get the APP to hang so your theory may still be
correct.
Pavel:
Thank you for the NOP trick, because I don't control the TLS evil.
As things has evolved I found that the APP was linked to a big complex
and for this app, unnecessary component.
After removing this, the initial problem with occasionally hung APP has
not been reproduced, so I will not invest the problem further.
Only a note:
I found that gflags -v image /disable app.exe
also removes the debug value from
...\Image File Execution Options\app.exe
I did not expect this behavior, maybe a minor bug ?
Regards
Kjell Gunnar.
Pavel Lebedinsky [MSFT]
> Thank you a lot, I did several runs with
>
> bp kernel32!CloseHandle "gu; j (@eax != 0) 'gc';'kv'"
>
> To catch a call to CloseHandle with illegal handle, but none
> observed.
This is actually not necessary. If your process has a debugger attached
then trying to close an invalid handle will raise an exception instead of
returning FALSE.