1

I have the following results of !analyze -hang -v on a dump file I have. I see that thread 0 is waiting for some handle to be released, as specified in derived_wait_chain. How can I get more information about this handle? !handle 784.183c returns an error...

0:000> !analyze -hang -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


FAULTING_IP: 
+0
00000000 ??              ???

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00000000
   ExceptionCode: 80000007 (Wake debugger)
  ExceptionFlags: 00000000
NumberParameters: 0

CONTEXT:  00000000 -- (.cxr 0x0;r)
eax=00000000 ebx=00000000 ecx=00000007 edx=00000000 esi=00000003 edi=00000003
eip=7725ca2c esp=0018edc4 ebp=0018ef4c iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
ntdll!NtWaitForMultipleObjects+0xc:
7725ca2c c21400          ret     14h

BUGCHECK_STR:  HANG

PROCESS_NAME:  scktsrvr.exe

ERROR_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code text>

EXCEPTION_CODE: (NTSTATUS) 0xcfffffff - <Unable to get error code text>

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

APP:  scktsrvr.exe

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) x86fre

DERIVED_WAIT_CHAIN:  

Dl Eid Cid     WaitType
-- --- ------- --------------------------
   0   784.183c Handle                 

WAIT_CHAIN_COMMAND:  ~0s;k;;

BLOCKING_THREAD:  0000183c

DEFAULT_BUCKET_ID:  APPLICATION_HANG_HungIn_ExceptionHandler

PRIMARY_PROBLEM_CLASS:  APPLICATION_HANG_HungIn_ExceptionHandler

PRIMARY_PROBLEM_CLASS_DATA:  .exr 0x18f558 / .cxr 0x18f5a8

LAST_CONTROL_TRANSFER:  from 7534112f to 7725ca2c

FAULTING_THREAD:  00000000

STACK_TEXT:  
0018edc0 7534112f 00000003 0018ef90 00000001 ntdll!NtWaitForMultipleObjects+0xc
0018ef4c 75817b89 00000003 0018ef90 00000000 KERNELBASE!WaitForMultipleObjectsEx+0xcc
0018ef68 758707bf 00000003 0018ef90 00000000 kernel32!WaitForMultipleObjects+0x19
0018f3a8 75870295 00000000 00000001 00000000 kernel32!WerpReportFaultInternal+0x50b
0018f3b8 75851709 0018f44c 753ef705 0018f45c kernel32!WerpReportFault+0x74
0018f3c0 753ef705 0018f45c 00000001 5931c527 kernel32!BasepReportFault+0x19
0018f44c 00403764 0018f45c 772600b1 0018f558 KERNELBASE!UnhandledExceptionFilter+0x1f4
WARNING: Stack unwind information not available. Following frames may be wrong.
0018f478 77260083 0018f558 0018ff74 0018f5a8 scktsrvr+0x3764
0018f540 772607ff 0018f558 0018f5a8 0018f558 ntdll!ExecuteHandler+0x24
0018f540 75344598 0018f558 0018f5a8 0018f558 ntdll!KiUserExceptionDispatcher+0xf
0018f8e8 0046f881 0eedfade 00000001 00000007 KERNELBASE!RaiseException+0x48
0018fefc 0046f987 0018ff4c 0018ff14 0046fa00 scktsrvr+0x6f881
0018ff4c 0046f502 00470bd4 7ffde000 00470ce3 scktsrvr+0x6f987
0018ff80 75817c04 7ffde000 75817be0 599eeb0a scktsrvr+0x6f502
0018ff94 7727ad1f 7ffde000 5b3cddf8 00000000 kernel32!BaseThreadInitThunk+0x24
0018ffdc 7727acea ffffffff 7726024e 00000000 ntdll!__RtlUserThreadStart+0x2f
0018ffec 00000000 00470bd4 7ffde000 00000000 ntdll!_RtlUserThreadStart+0x1b


FOLLOWUP_IP: 
scktsrvr+3764
00403764 83f800          cmp     eax,0

SYMBOL_STACK_INDEX:  7

SYMBOL_NAME:  scktsrvr+3764

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: scktsrvr

IMAGE_NAME:  scktsrvr.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  2a425e19

STACK_COMMAND:  ~0s ; kb

BUCKET_ID:  HANG_scktsrvr+3764

FAILURE_BUCKET_ID:  APPLICATION_HANG_HungIn_ExceptionHandler_cfffffff_scktsrvr.exe!Unknown

ANALYSIS_SOURCE:  UM

FAILURE_ID_HASH_STRING:  um:application_hang_hungin_exceptionhandler_cfffffff_scktsrvr.exe!unknown

FAILURE_ID_HASH:  {45df6cc2-89e8-d20a-efde-b2365e4d9c6c}

Followup: MachineOwner
---------
Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
user884248
  • 2,134
  • 3
  • 32
  • 57
  • Looks like you have an unhandled exception in your application. If it's a Delphi app, then it's throwing an "Exception-derived object". I'd inspect it as the debugger suggests with `.exr 0x18f558` or `.excr`. To switch thread context to the exception-throw point: `.cxr 0x18f5a8` – deemok Aug 03 '15 at 11:22
  • Hey @deemok - thanks again for helping out. Is there any way to contact you privately? – user884248 Aug 03 '15 at 12:53
  • you can use the address on my github profile. – deemok Aug 03 '15 at 14:14

1 Answers1

1

784 is the process ID (PID) and 183c is the thread ID (TID) of the thread waiting. To get more information about the handle it is waiting on, switch to the thread and get a call stack with parameters (kb on 32 bit). This will give you a call to WaitForMultipleObjects() or WaitForSingleObject() and from the parameters you'll get the handle(s) it waits for.

In your case, the stack is listed as part of !analyze:

STACK_TEXT:  
0018edc0 7534112f 00000003 0018ef90 00000001 ntdll!NtWaitForMultipleObjects+0xc
0018ef4c 75817b89 00000003 0018ef90 00000000 KERNELBASE!WaitForMultipleObjectsEx+0xcc
0018ef68 758707bf 00000003 0018ef90 00000000 kernel32!WaitForMultipleObjects+0x19

Looking at MSDN, it says

DWORD WINAPI WaitForMultipleObjects(
  _In_       DWORD  nCount,
  _In_ const HANDLE *lpHandles,
  _In_       BOOL   bWaitAll,
  _In_       DWORD  dwMilliseconds
);

So this thread waits for 3 handles and at address 0018ef90 there are three handles for which you can get more information with !handle.

However, it seems that the real problem is just hidden behind the "Send error report to Microsoft" functionality of Windows.

From the parameters to ntdll!KiUserExceptionDispatcher(), which are an exception record and an exception context, you can find out more about the original exception. As mentioned by @deemok, .exr 0x18f558 and .cxr 0x18f5a8 should bring up more information.

From the parameters to KERNELBASE!RaiseException(), the exception code is 0x0eedfade, which is typical for a Delphi application. Marc Durdin has a nice post about the analysis of Delphi exceptions with WinDbg.

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222