Questions about WER dumps

Hello,

I have a W7 computer that periodically produces WER dumps in a batch (say 3 - 6 dumps) all at the same time, but each "batch" of dumps will be for different applications (i.e. there is no obvious pattern).

I have inspected some of these dumps with Windbg and while I am a novice at analysing dumps, the errors for each dump appear to be different (e.g. different exceptions etc.); there is no common pattern that I can see.

The WER dumps are being produced with the default configuration, I have not for instance configured Full User-Mode dumps.

The questions that I have:

- If I were to configure Full User-Mode dumps, would this result in a BSOD?
- Is it likely that a Full User-Mode dump could provide more useful diagnostic info, or is a kernel dump far more likely to be of use?

Thank you.

User-mode dumps shouldn't result in a BSOD because a BSOD is a bugcheck produced in kernel-mode. Nothing in user-mode is run on privileged code so it can't access critical OS system files, it has to go through one or more subroutines implemented in Dynamic link Libraries.

A user mode dump contains the entire memory space of a process, a kernel dump contains all memory used by the kernel at the time of a system crash. A user-mode application contains it's own private VAD (Virtual Address Space) so that no other application can alter it. Kernel mode shares a single VAD so if a driver crashes in kernel mode the entire OS crashes, usually resulting in a bugcheck.

It depends on what you are trying to diagnose.

matts6887 said:

I would definitely consider doing a full mode diagnostic; as doing that i would think would give more insight as to what is going on. You also might want to check the event viewer for error messages and see what they say if they do in fact show anything.

Hi,

I have examined the Event Log error messages and have even posted them on some forums (although not here), unfortunately so far the Event Log error messages have proved to be inconclusive. Which got me thinking about trying to analyse the dumps that WER is producing.

I will enable Full mode dumps and see if they result in more useful info being produced.

Thedoctor44 said:

User-mode dumps shouldn't result in a BSOD because a BSOD is a bugcheck produced in kernel-mode. Nothing in user-mode is run on privileged code so it can't access critical OS system files, it has to go through one or more subroutines implemented in Dynamic link Libraries.

A user mode dump contains the entire memory space of a process, a kernel dump contains all memory used by the kernel at the time of a system crash. A user-mode application contains it's own private VAD (Virtual Address Space) so that no other application can alter it. Kernel mode shares a single VAD so if a driver crashes in kernel mode the entire OS crashes, usually resulting in a bugcheck.

It depends on what you are trying to diagnose.

Thanks for the explanation. My gut feel was that this was likely to be the case, but as this computer is being used by other users I don't want it to BSOD.

If I'm going to generate BSOD's I'd most likely backup and restore the image to another system first (which in itself eliminates the current hardware as a source of the issue). However there are some logistical reasons why this will not be straightforward so I'd like to try and diagnose on the current box initially.

As for what I'm trying to diagnose, well basically why are the errors occurring. As I mentioned in my first post, most days (at some stage) there will be a group of WER events reported in the Event Log. They will be for different applications, and so far there is no clear pattern other than the fact that when the errors occur, they occur in a cluster of 5 - 6 errors at the same time. Because multiple applications are being affected; I'm thinking that the underlying cause is either some OS dependency (e.g. .NET framework or some other application dependency).

Of course it could be hardware. but in my experience most hardware issues tend to affect Windows stability, which is not the case here, and I have run diagnostics on the hardware anyway which are clear. So my gut feel is that the issue is "software", but what exactly, I have no idea

Hello,

At 9:24 I had another series of errors occur.

Key logs attached.

Because of file size restrictions I could not upload this log, but I suspect that it may hold useful info as in this case it was the first error reported and the largest dump.

Download AppCrash_ActEmail.exe_5b5279ec6881f8c2ebbf6c8b4d2fdb9665ce4bc_cab_3079c0af.zip from Sendspace.com - send big files the easy way

Thanks
VW

Hello,

I performed Exception Analysis on the ActEmail dump, and I have a couple of questions that hopefully I can get some help with.

The analysis is here:

Code:

*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

Unable to load image C:\Windows\System32\mfc100u.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for mfc100u.dll
The version of SOS does not match the version of CLR you are debugging.  Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.18408
SOS Version: 4.0.30319.1008
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of clr.dll is 
                in the version directory
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
            4) you are debugging on the same architecture as the dump file.
                For example, an IA64 dump file must be debugged on an IA64
                machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to clr.dll as well.
The version of SOS does not match the version of CLR you are debugging.  Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.18408
SOS Version: 4.0.30319.1008
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of clr.dll is 
                in the version directory
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
            4) you are debugging on the same architecture as the dump file.
                For example, an IA64 dump file must be debugged on an IA64
                machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to clr.dll as well.

FAULTING_IP: 
ActEmail+53beb
00453beb 8b10            mov     edx,dword ptr [eax]

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00453beb (ActEmail+0x00053beb)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000000
   Parameter[1]: 00000000
Attempt to read from address 00000000

PROCESS_NAME:  ActEmail.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at "0x%08lx" referenced memory at "0x%08lx". The memory could not be "%s".

EXCEPTION_PARAMETER1:  00000000

EXCEPTION_PARAMETER2:  00000000

READ_ADDRESS:  00000000 

FOLLOWUP_IP: 
msvcrt!_EH4_CallFilterFunc+12
75583f21 5b              pop     ebx

MOD_LIST: <ANALYSIS/>

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

MANAGED_STACK: !dumpstack -EE
The version of SOS does not match the version of CLR you are debugging.  Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.18408
SOS Version: 4.0.30319.1008
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of clr.dll is 
                in the version directory
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
            4) you are debugging on the same architecture as the dump file.
                For example, an IA64 dump file must be debugged on an IA64
                machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to clr.dll as well.

LAST_CONTROL_TRANSFER:  from 004011c7 to 00453beb

FAULTING_THREAD:  00002534

BUGCHECK_STR:  APPLICATION_FAULT_NULL_POINTER_READ_WRONG_SYMBOLS_SILENT

PRIMARY_PROBLEM_CLASS:  NULL_POINTER_READ_SILENT

DEFAULT_BUCKET_ID:  NULL_POINTER_READ_SILENT

STACK_TEXT:  
WARNING: Stack unwind information not available. Following frames may be wrong.
0018f558 004011c7 00000001 84cd108e 0018f644 ActEmail+0x53beb
0018f58c 7599592c 01e8e4f4 00000000 00000202 ActEmail+0x11c7
0018f5a8 75a105f1 00401170 0018f790 00000002 rpcrt4!Invoke+0x2a
0018f9ac 753faec1 006e2ea8 006e8238 006f0ab0 rpcrt4!NdrStubCall2+0x2ea
0018f9f4 768cffd3 006e2ea8 006f0ab0 006e8238 ole32!CStdStubBuffer_Invoke+0x3c [d:\w7rtm\com\rpc\ndrole\stub.cxx @ 1507]
0018fa18 753fd876 006e2ea8 006f0ab0 006e8238 oleaut32!CUnivStubWrapper::Invoke+0xcb
0018fa60 753fddd0 006f0ab0 006f1cb8 006f2ab0 ole32!SyncStubInvoke+0x3c [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1187]
0018faac 75318a43 006f0ab0 006f45e0 006de040 ole32!StubInvoke+0xb9 [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1396]
0018fb88 75318938 006e8238 00000000 006de040 ole32!CCtxComChnl::ContextInvoke+0xfa [d:\w7rtm\com\ole32\com\dcomrem\ctxchnl.cxx @ 1262]
0018fba4 7531950a 006f0ab0 00000001 006de040 ole32!MTAInvoke+0x1a [d:\w7rtm\com\ole32\com\dcomrem\callctrl.cxx @ 2105]
0018fbd0 753fdccd 006f0ab0 00000001 006de040 ole32!STAInvoke+0x46 [d:\w7rtm\com\ole32\com\dcomrem\callctrl.cxx @ 1924]
0018fc04 753fdb41 d0908070 006e8238 006de040 ole32!AppInvoke+0xab [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1086]
0018fce4 753fe1fd 006f0a58 006e8628 00000400 ole32!ComInvokeWithLockAndIPID+0x372 [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1724]
0018fd0c 75319367 006f0a58 00000400 0063fb98 ole32!ComInvoke+0xc5 [d:\w7rtm\com\ole32\com\dcomrem\channelb.cxx @ 1469]
0018fd20 75319326 006f0a58 00000000 75319286 ole32!ThreadDispatch+0x23 [d:\w7rtm\com\ole32\com\dcomrem\chancont.cxx @ 298]
0018fd64 756962fa 000516cc 00000400 0000babe ole32!ThreadWndProc+0x161 [d:\w7rtm\com\ole32\com\dcomrem\chancont.cxx @ 654]
0018fd90 75696d3a 75319286 000516cc 00000400 user32!InternalCallWinProc+0x23
0018fe08 756977c4 00000000 75319286 000516cc user32!UserCallWinProcCheckWow+0x109
0018fe68 7569788a 75319286 00000000 0018fea8 user32!DispatchMessageWorker+0x3bc
0018fe78 77e61801 00637c98 00000000 004e64b0 user32!DispatchMessageW+0xf
0018fe88 77e61e89 004e64b0 004e64b0 ffffffff mfc100u!AfxInternalPumpMessage+0x40
0018fea8 004059be 84cd1be2 004e64b0 004e64b0 mfc100u!CWinThread::Run+0x5b
0018fee0 77e8778d 004e7500 00000001 00000000 ActEmail+0x59be
0018fef4 0048674e 00400000 00000000 00621ce4 mfc100u!AfxWinMain+0x6a
0018ff88 76bf336a 7efde000 0018ffd4 77189f72 ActEmail+0x8674e
0018ff94 77189f72 7efde000 742c7bcb 00000000 kernel32!BaseThreadInitThunk+0xe
0018ffd4 77189f45 00486881 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70
0018ffec 00000000 00486881 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b


SYMBOL_STACK_INDEX:  7

SYMBOL_NAME:  msvcrt!_EH4_CallFilterFunc+12

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: msvcrt

IMAGE_NAME:  msvcrt.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  4eeaf722

STACK_COMMAND:  .cxr 00000000 ; kb ; ~0s; .ecxr ; kb

FAILURE_BUCKET_ID:  NULL_POINTER_READ_SILENT_c0000005_msvcrt.dll!_EH4_CallFilterFunc

BUCKET_ID:  APPLICATION_FAULT_NULL_POINTER_READ_WRONG_SYMBOLS_SILENT_msvcrt!_EH4_CallFilterFunc+12

WATSON_IBUCKET:  -484836627

WATSON_IBUCKETTABLE:  1

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne...htm?Retriage=1

Followup: MachineOwner
---------

I believe that I'm using the latest version of WinDbg for Win7 x86, which I'm running on XP, help about reports v6.12.0002.633 x86. But the log is stating that I need at least v6.2.14. Is that correct or does this indicate that there is something wrong with my setup?

The log states that I need to be debugging the dump on the same architecture as the dump file. So if the dump was produced on Win7 x64, then I need to run debug tools in that environment. It was my understanding that this was not the case. Would appreciate if someone could clarify.

Thank you