Re: Strange call stack after using !analyze -v

WinDbg

Strange call stack after using !analyze -v

---

Jonas 2012-05-08, 18:23 下午
老师您好：
  我最近碰到一个问题， dump是用procdump这个工具抓的，运行命令!analyze -v显示如下：
  FAULTING_IP:
ntdll!KiRaiseUserExceptionDispatcher+3a
00000000`7764f6b7 8b8424c0000000  mov     eax,dword ptr [rsp+0C0h]

EXCEPTION_RECORD:  ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 000000007764f6b7 (ntdll!KiRaiseUserExceptionDispatcher+0x000000000000003a)
   ExceptionCode: c0000008 (Invalid handle)
  ExceptionFlags: 00000000
NumberParameters: 0
Thread tried to close a handle that was invalid or illegal to close

DEFAULT_BUCKET_ID:  STATUS_INVALID_HANDLE

PROCESS_NAME:  store.exe

ERROR_CODE: (NTSTATUS) 0xc0000008 - An invalid HANDLE was specified.

EXCEPTION_CODE: (NTSTATUS) 0xc0000008 - An invalid HANDLE was specified.

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

STACK_ADDR_RAW_STACK_SYMBOL: b535afa20

ADDITIONAL_DEBUG_TEXT:  Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[ffffffff]

LAST_CONTROL_TRANSFER:  from 000007fefd6b1853 to 000000007764f6b7

FAULTING_THREAD:  ffffffffffffffff

PRIMARY_PROBLEM_CLASS:  STATUS_INVALID_HANDLE

BUGCHECK_STR:  APPLICATION_FAULT_STATUS_INVALID_HANDLE

STACK_TEXT: 
000007fe`fd6b9aef KERNELBASE+0x9aef
000007fe`fd6e39d2 KERNELBASE+0x339d2
000007fe`fd6e38fc KERNELBASE+0x338fc
000007fe`fd6b1aab KERNELBASE+0x1aab
00000000`7752c193 kernel32+0x4c193
0000000b`52427812 utilDebug!apr_file_unlock+0x42
00000000`7750309a kernel32+0x2309a
0000000b`524198f0 utilDebug!apr_file_write+0x200
0000000b`523df60c utilDebug!log4cxx::helpers::FileOutputStream::write+0x9c
0000000b`523839d3 utilDebug!log4cxx::helpers::Transcoder::encodeUTF8+0x13
0000000b`523900be utilDebug!log4cxx::helpers::UTF8CharsetEncoder::encode+0x2e
0000000b`52390511 utilDebug!log4cxx::helpers::CharsetEncoder::encode+0x21
0000000b`5237676c utilDebug!log4cxx::rolling::CountingOutputStream::write+0x2c
0000000b`5238e9d1 utilDebug!log4cxx::helpers::OutputStreamWriter::write+0x141
00000001`3ef96e97 msvcr80!malloc+0x67
00000000`77718288 ntdll!RtlpInterceptorRoutines+0x0
00000000`77651468 ntdll!RtlAllocateHeap+0xe4
00000001`3f01698f msvcr80!memcpy_s+0x6f
0000000b`5253bfbb msvcp80!std::basic_string<unsigned short,std::char_traits<unsigned short>,std::allocator<unsigned short> >::basic_string<unsigned short,std::char_traits<unsigned short>,std::allocator<unsigned short> >+0x2b
0000000b`52536467 msvcp80!std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::append+0x127
0000000b`524499f0 utilDebug!log4cxx::helpers::ObjectPtrT<log4cxx::Logger>::`vftable'+0x0
0000000b`5244b208 utilDebug!log4cxx::helpers::ObjectPtrT<log4cxx::spi::Filter>::`vftable'+0x0
0000000b`5241ac05 utilDebug!apr_thread_mutex_unlock+0x15
0000000b`52534189 msvcp80!std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::~basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >+0x19
0000000b`5235fe82 utilDebug!log4cxx::WriterAppender::subAppend+0xb2
0000000b`5235e971 utilDebug!log4cxx::WriterAppender::append+0x31
00000000`7764c9b0 ntdll!RtlLeaveCriticalSection+0x7b
0000000b`5238541f utilDebug!log4cxx::helpers::synchronized::~synchronized+0xf
00000000`77502a8a kernel32+0x22a8a
00000001`3ef96dfb msvcr80!free+0x1b
0000000b`5244c790 utilDebug!log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggingEvent>::`vftable'+0x0
0000000b`52369aa4 utilDebug!log4cxx::helpers::MessageBuffer::~MessageBuffer+0x34
0000000b`523822d2 utilDebug!log4cxx::helpers::ObjectImpl::releaseRef+0x12
00000000`698f373c hookVsapi+0x2373c
0000000b`52350847 utilDebug!Log4cxxAdapter::WriteLog+0x237
0000000b`5244ab20 utilDebug!log4cxx::helpers::ObjectPtrBase::`vftable'+0x0
0000000b`5244859a utilDebug!`string'+0x0
00000000`698f3738 hookVsapi+0x23738
0000000b`5233f76b utilDebug!DBG::DebugLogEx+0x10b
00000000`77522ee8 kernel32+0x42ee8
00000000`77541554 kernel32+0x61554
00000000`77579337 kernel32+0x99337
00000001`3ef93ed9 msvcr80!_getptd_noexit+0x79
00000000`776377ba ntdll!RtlDecodePointer+0x2a
00000000`777290c4 ntdll!`string'+0xbf44
00000000`77696258 ntdll! ?? ::FNODOBFM::`string'+0x22c5
00000000`77634dc1 ntdll!RtlLookupFunctionTable+0xbd
00000001`3efcabe7 msvcr80!__CxxFrameHandler+0x77
00000000`77668115 ntdll! ?? ::FNODOBFM::`string'+0xd52d
00000000`7760b3a3 ntdll! ?? ::FNODOBFM::`string'+0x13548
00000000`77614ebc ntdll!_C_specific_handler+0x0
00000000`777290b8 ntdll!`string'+0xbf38
00000000`698d8540 hookVsapi+0x8540
000007fe`fd6b1865 KERNELBASE+0x1865
00000000`77748334 ntdll!CsrPortMemoryRemoteDelta <PERF> +0x0
000007fe`fd6b0000 KERNELBASE+0x0
000007fe`fd7130c0 KERNELBASE+0x630c0
00000000`775eedb4 kernel32+0x10edb4
00000000`698d0000 hookVsapi+0x0
00000000`69901894 hookVsapi+0x31894
00000001`3f04f348 msvcr80!_bufin <PERF> +0x0
00000001`3ef90000 msvcr80!_initp_heap_handler <PERF> +0x0
00000001`3f04f360 msvcr80!_bufin <PERF> +0x0
00000000`774e0000 kernel32+0x0
00000000`775ee940 kernel32+0x10e940
00000000`77600000 ntdll!RtlActivateActivationContext <PERF> +0x0
00000000`77745940 ntdll!CsrPortMemoryRemoteDelta <PERF> +0x0
00000000`7769db00 ntdll! ?? ::FNODOBFM::`string'+0x140f9
00000000`7764f65d ntdll!KiUserExceptionDispatcher+0x53
00000000`7764f6b7 ntdll!KiRaiseUserExceptionDispatcher+0x3a
000007fe`fd6b1853 KERNELBASE+0x1853
00000000`77502a51 kernel32+0x22a51
00000000`698f3670 hookVsapi+0x23670
00000000`698f3578 hookVsapi+0x23578
00000000`698d87fe hookVsapi+0x87fe
00000000`698f34e0 hookVsapi+0x234e0
00000001`3ef93f69 msvcr80!_getptd+0x79
00000001`3ef937d7 msvcr80!_callthreadstartex+0x17
00000001`3ef93894 msvcr80!_threadstartex+0x84
00000001`3f0495c0 msvcr80!__initialmbcinfo+0x0
00000000`774ff33d kernel32+0x1f33d
00000000`77632ca1 ntdll!RtlUserThreadStart+0x1d
00000000`77579280 kernel32+0x99280


FOLLOWUP_IP:
KERNELBASE+9aef
000007fe`fd6b9aef ??              ???

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  KERNELBASE+9aef

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: KERNELBASE

IMAGE_NAME:  KERNELBASE.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  4e211da1

STACK_COMMAND:  ddS b535b0000 b53596000 ; dds b53596d08 ; kb

为什么线程的ID是ffffffffffffffff， 而且我用~*kb命令打印所有线程的call stack， 却没有上面提到的call stack, 请问这是为什么？

一般发现“Thread tried to close a handle that was invalid or illegal to close” 这种error应该怎么解决？

Re: Strange call stack after using !analyze -v

---

格蠹老雷 2012-05-17, 13:42 下午

著名的无效句柄问题；很是巧合，这一期（6月）《程序员》杂志的专栏就是这个内容“谁关了我的句柄”。

如果问题可以重现，那么先使用App Verifier开启句柄监视功能，再重现问题，非常有效。

如果问题难以重现，只能继续分析这个dump，那么先解决符号问题，kernelbase模块的符号不对...