Wrong COM+ dump files or wrong event log error report.
news.microsoft.com
intermittently we get errors like
Exception: C0000005
Address: 0x7C342CD0
Call Stack:
MSVCR71!strcmp + 0x10
CI_Motor! + 0x10129
CI_Motor!DllUnregisterServer + 0x2f874
...
CI_Motor!DllUnregisterServera + 0xe723
CI_Motor!DllUnregisterServer + 0x1709c
OLEAUT32!DispCallFunc + 0x15d
OLEAUT32!CreateTypeLib2 + 0x2e1b
CI_Motor!DllGetClassObject + 0xa23
OLEAUT32!VarDecCmp + 0x1537
OLEAUT32!VarDecCmp + 0x35f
RPCRT4!CStdStubBuffer_Invoke + 0x82
OLEAUT32!VariantChangeType + 0xb36b
ole32!StgGetIFillLockBytesOnFile + 0x11105
ole32!StgGetIFillLockBytesOnFile + 0x110af
ole32!CoGetMalloc + 0x1a4b
We have installed the right pdb in the server and in this way the first
thing I surprise very much is why DllUnregisterServer like functions are
printed ? , The crash generated a dump file but the information shown here
is different what event log shown, Why call stack, error, ... shown in the
dump file are completely different what are shown in event long?
Although the call stack was corrupted I suppose that the first function
printed are rigth (EIP), and I suppose too that the exception code must be
the same, but event log show a C0000005 a windbg show a 80000003. If I open
de dump file with Visual Studio C++ 7.0 instead of windbg the information
reported is very similar to windbg, then Can I suppose that event log crash
is wrong?
If event log report was right I can say that a stack memory corruption was
raised because the second function printed in the call stack is CI_Motor! +
0x10129 which offset is not a valid instruction, but a strcmp don't produce
memory corruption.
EXCEPTION_RECORD: ffffffff -- (.exr ffffffffffffffff)
.exr ffffffffffffffff
ExceptionAddress: 00000000
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 0
FAULTING_THREAD: 0000166c
BUGCHECK_STR: 80000003
DEFAULT_BUCKET_ID: APPLICATION_FAULT
PROCESS_NAME: dllhost.exe
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Break point.
THREAD_ATTRIBUTES:
LAST_CONTROL_TRANSFER: from 77f43741 to 7ffe0304
STACK_TEXT:
0006fcd8 77f43741 77e41817 00000038 00000000
SharedUserData!SystemCallStub+0x4
0006fcdc 77e41817 00000038 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc
0006fd4c 77e4168f 00000038 ffffffff 00000000
kernel32!WaitForSingleObjectEx+0xac
0006fd5c 7720aa16 00000038 ffffffff ffffffff
kernel32!WaitForSingleObject+0xf
0006fd78 7720b48c 00089340 0006fdb7 00000000
ole32!CSurrogateProcessActivator::WaitForSurrogateTimeout+0x49
0006fd90 0100137c 0006ff08 00000000 00000000
ole32!CoRegisterSurrogateEx+0x1a4
0006ff1c 01001646 01000000 00000000 00082390 dllhost!WinMain+0xda
0006ffc0 77e4f38c 00000000 00000000 7ffdf000 dllhost!WinMainCRTStartup+0x182
0006fff0 00000000 010014c4 00000000 78746341 kernel32!BaseProcessStart+0x23
If I execute in windbg a lm command a can view as the pdb are loaded
perfectly
60000000 600cd000 CI_Motor C (private pdb symbols) c:\windbg\CI_Motor.pdb
Anybode can say me if I was doing something wrong because I was very very
lost.
Thanks very much.
Pavel Lebedinsky
"news.microsoft.com" <aguja...@terra.es> wrote:
Looks like COM+ didn't load symbols when creating this stack trace.
You can try setting your _NT_SYMBOL_PATH env. variable to
something like
_NT_SYMBOL_PATH=SRV*c:\symbols*http://msdl.microsoft.com/download/symbols;c:\mysymbols
where c:\symbols would be the local cache for OS symbols
downloaded from the symbol server, and c:\mysymbols is
where you put CI_Motor.pdb.
Most likely you'll need to reboot for the change to take effect.
> Although the call stack was corrupted I suppose that the first function
> printed are rigth (EIP), and I suppose too that the exception code must be
> the same, but event log show a C0000005 a windbg show a 80000003. If I
> open
> de dump file with Visual Studio C++ 7.0 instead of windbg the information
> reported is very similar to windbg, then Can I suppose that event log
> crash
> is wrong?
You could be looking at a different thread. Dump all stack traces with
~*k and see if there's anything similar to what the exception log
shows, or if there are any functions whose names contain "ExceptionFilter".
Diego Fernández Santos
Effectively we have an incorrect pdb version installed in the server, after
updating the pdb we began to get right event log error report. Here I send
you a copy of the new event log report:
Exception: C0000005
Address: 0x102160F0
Call Stack:
MSVCR71D!strcmp + 0x10
CI_Motor!FormatVector + 0x254
CI_Motor!CEstadoGraph::DrawDataQuery + 0xce9
CI_Motor!CEstadoGraph::SetPresentacion + 0x2a7
CI_Motor!CEstadoGraph::EjecutarInforme + 0xe3
CI_Motor!CEstado::InitDocument + 0x1161
CI_Motor!CEstadoGraph::InitDocument + 0x6d
CI_Motor!CEstadoGraph::OpenDocument + 0x231
CI_Motor!CComInformes::OpenInformeEx + 0x878a
CI_Motor!CComInformes::OpenInforme + 0x1e3
As you can watch in the call stack, now all functions seems to work
correctly.
When we open the dump with windbg using "~*k" command we realize that there
is a thread which has an ExceptionFilter function:
8 Id: 1754.1624 Suspend: 0 Teb: 7ffda000 Unfrozen
ChildEBP RetAddr
00784e8c 77f43741 SharedUserData!SystemCallStub+0x4
00784e90 77e41817 ntdll!ZwWaitForSingleObject+0xc
00784f00 77e4168f kernel32!WaitForSingleObjectEx+0xac
00784f10 7568282c kernel32!WaitForSingleObject+0xf
00785398 75682be5 comsvcs!FF_RunCmd+0x9d
00785660 75682cf3 comsvcs!FF_DumpProcess_MD+0x218
007858a4 7568338d comsvcs!FF_DumpProcess+0x36
00785e00 755f32f4 comsvcs!FailFastStr+0x267
00785e28 7560f1ec comsvcs!ComSvcsExceptionFilter+0x9a
00785e38 77207c0b comsvcs!CContext::ServerException+0xd
00785e58 7720cbab ole32!CObjectContext::NotifyServerException+0x75
00785e70 7726cc20 ole32!AppInvokeExceptionFilter+0x34
0078fa6c 7726aa7f ole32!SyncStubInvoke+0x6a
0078fab4 77163858 ole32!StubInvoke+0xa5
0078fb8c 7716377d ole32!CCtxComChnl::ContextInvoke+0xe3
0078fba8 7726a6b0 ole32!MTAInvoke+0x18
0078fbd8 7726a71b ole32!AppInvoke+0x9a
0078fca4 7726ad87 ole32!ComInvokeWithLockAndIPID+0x2be
0078fcec 77c57337 ole32!ThreadInvoke+0x1de
0078fd20 77c571f9 rpcrt4!DispatchToStubInCNoAvrf+0x38
However none of the threads shows a MSVCR71D!strcmp function in the call
stack. Why I can not view this function in any call stack?
Another question is, why with a "analyze -v" windbg show me a breakpoint
error instead of a violation access memory?
A question that I have not very clear is what the "analyze -v -hang" command
do?, if I change the current thread to which show a ExceptionFilter function
and then I run a "analyze -v -hang" command I get another report:
FOLLOWUP_IP:
comsvcs!FF_RunCmd+9d
7568282c 8d45d4 lea eax,[ebp-0x2c]
SYMBOL_STACK_INDEX: 4
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: comsvcs!FF_RunCmd+9d
MODULE_NAME: comsvcs
IMAGE_NAME: comsvcs.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 40566fcc
STACK_COMMAND: ~8s ; kb
BUCKET_ID: HANG_dllhost.exe_comsvcs!FF_RunCmd+9d
"Pavel Lebedinsky" <m_pll at hotmail com> escribió en el mensaje
news:OB9Alsp9...@TK2MSFTNGP12.phx.gbl...
Ivan Brugiolo [MSFT]
saved by the exception dispatch code in order to get the
real stack "behind" the exception being dispatched
on the thread reported all the way down below.
Among other possible methods, if you execute the command below
0:001> ~*e s -d poi(@$teb+8) poi(@$teb+4) 1003f
you should have the addressed where to find the context record.
Do a `.cxr <address>;kb` on the addressed returned by the previous command,
and look at them for possible problems/errors.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Diego Fernández Santos" <dfd...@bankinter.es> wrote in message
news:#qGOcux9...@TK2MSFTNGP15.phx.gbl...
Diego Fernández Santos
What I don't understand very well is why you are looking for a 1003f dw to
find the context record?
Very thanks again Ivan.
"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> escribió en el
mensaje news:OETKgxz9...@TK2MSFTNGP09.phx.gbl...
Pavel Lebedinsky
0x1003f is CONTEXT_ALL for x86 (you can find the definitions
of all context flags in winnt.h).
On x86 CPUs that don't have extended registers (like some AMD
models I think) you might have to use 1001f instead (which is
CONTEXT_ALL minus the CONTEXT_EXTENDED_REGISTERS flag).