Multiple crashes of Explorer

I have good and bad days. on bad days, Explorer crashes 10 or so times a day. Here's the details:

Problem signature:
Problem Event Name: APPCRASH
Application Name: Explorer.EXE
Application Version: 6.1.7600.16385
Application Timestamp: 4a5bc9bb
Fault Module Name: StackHash_3aac
Fault Module Version: 6.1.7600.16385
Fault Module Timestamp: 4a5be02b
Exception Code: c0000374
Exception Offset: 00000000000c6cd2
OS Version: 6.1.7600.2.0.0.256.1
Locale ID: 1033
Additional Information 1: 3aac
Additional Information 2: 3aac27612f55de5fedc05a5b0c1eeda1
Additional Information 3: b8d0
Additional Information 4: b8d018ca52c0d57f12158de2274a7f2b
************


Any help or insight?

usasma said:

Not much other than it's a heap corruption ( c0000374 ).
Please generate a dump file of explorer.exe as soon as you notice the crash happening. To do this, right click on Explorer.exe in the Processes tab of Task Manager and select "Create dum file".

Note where the dump file ends up, upload it to a file hosting service and let us know the link to download it from.

Unfortunately, that method of dump file collection doesn't work well with crashes. To be useful, the dump has to capture the stack of the offending thread at the precise point where the exception is thrown. If you're off by mere microseconds, you'll see either the aftermath or nothing at all. (It's a good way to get dumps of hung processes though - if they're so badly hung that you've got seconds or even minutes to act.)

In XP, it was simpler to configure user-mode dump collection, even though it didn't always work. Because the Dr.Watson mechanism relied on injecting code, it wouldn't succeed in situations where the stack was smashed or exhausted. In Vista and Win7, the WERSVC is far more robust, but it also makes it necessary to jump through more hoops to get a crash dump.
=========================


@Dockster: can you repro this crash or is it something that seems to happen relatively randomly?

[quote=usasma;307845]Thanks for explaining that H2SO4! No wonder I don't get much when I try that! :)

No problem Usasma :)

usasma said:

Would the output of msinfo32.exe or eventvwr.msc collect more info on the crash?

Short version: no, it's unlikely to help.

Longer version: <to be penned after I come back from playing "errand boy" for my wife>.

usasma said:

Would the output of msinfo32.exe or eventvwr.msc collect more info on the crash?

There are at least two fundamental issues here:

a) Extracting any sort of dump from the affected system at the point of the crash.
b) Making sure the dump is actually useful.

======================================

Regarding (a), there are any number of ways to get user-mode crash dumps, but the most relevant ones for our purposes are:

1. Configure the in-built WERSVC to create a dump when it's informed by the kernel of a second-chance exception. It only takes a single registry modification ("ForceQueue") for the default settings. I did a basic write-up just now:

https://www.sevenforums.com/crashes-d...tml#post308170

2. Download the "debugging tools" package onto the machine in question and use either the debugger itself or the ADPlus script (preferred) to latch onto the process in question and wait for a crash. Example:

adplus -crash -MiniOnSecond -pn explorer.exe

Should the process being monitored crash (suffer a second-chance exception), adplus causes CDB to generate a dump.

Method (1) is simpler because it doesn't require any downloads, but (2) is more powerful and granular. In certain situations you can't do without (2).

======================================

Regarding (b), as you pointed out this is a likely heap corruption scenario, which means that the dump itself is unlikely to show the true culprit. To get info at the time of the actual corruption rather than somewhere down the track, it's necessary to first activate "pageheap" or one of the other associated extra-scrutiny heap mechanisms for the process in question. This is analogous to the way that special pool is used for kernel-mode pool corruption issues.

The GFLAGS utility in the debug tools package can make the job of modifying IFEO (Image File Execution Options) settings in the registry for a given process somewhat easier. For example, to enable pageheap for Explorer:

gflags /p /enable Explorer.exe
<restart the process>

After that, crashes should occur durring attempted heap overruns, not afterwards when the mangled heap memory is being accessed.

Hope this helps :)

Wow -- you guys are way beyond me as far as debugging knowledge. In any case, I haven't had any more crashes but when I do, I will try to gather more information. by the way, are the instructions the same for x64?

dockster said:

... I haven't had any more crashes but when I do, I will try to gather more information. by the way, are the instructions the same for x64?

Yes. If you go through this registry edit procedure...

https://www.sevenforums.com/crashes-d...tml#post308170

... you should have a shiny new memory dump the next time Explorer (or anything else for that matter) crashes on your system. Analysis of the memory dump is an initial step in understanding the cause.

As Usasma pointed out, the specific type of crash in your instance is complex and further steps may be necessary later.

I find that when my explorer crashes it won't stop crashing.


For example. explorer crashes when right clicking and icon. Explorer reloads and I try to right click that icon....explorer crashes again. Continues until I reboot.

Lunarpancake said:

I find that when my explorer crashes it won't stop crashing.


For example. explorer crashes when right clicking and icon. Explorer reloads and I try to right click that icon....explorer crashes again. Continues until I reboot.

That would be because the same bug in the non-default context menu handler which made it crash the first time is still there when you right-click the second time after a process restart :)