# App crashing - 0xc0000374 and 0xc0000005 exception code



## Satanas

Hi all,

I've recently encountered a weird issue with app crashing that I never encountered before.

The first is Media Player Classic Home Cinema (Kawaii Codec Pack). It never used to crash before, now sometimes upon opening a file with it, I get the following:


Code:


Faulting application name: mpc-hc.exe, version: 1.6.8.7153, time stamp: 0x518589d8
Faulting module name: ntdll.dll, version: 6.2.9200.16578, time stamp: 0x515fac6e
Exception code: 0xc0000374
Fault offset: 0x000daa3c
Faulting process id: 0x11b0
Faulting application start time: 0x01ce578916d97a9b
Faulting application path: C:\Program Files (x86)\Kawaii Codec Pack\MPC-HC\mpc-hc.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 560a9fe6-c37c-11e2-bebe-00248ca1b4ce
Faulting package full name: 
Faulting package-relative application ID:

This happens 1/5-1/10 times I open a media file, then I have to reopen MPC and hope it doesn't happen again.

At first I thought this might be a software issue so I ignored that it suddenly began happening. Then randomly when I opened CoreTemp, which I use all the time without issue, I got the following



Code:


Faulting application name: Core Temp.exe, version: 1.0.0.0, time stamp: 0x5130cd0e
Faulting module name: ntdll.dll, version: 6.2.9200.16579, time stamp: 0x51637f77
Exception code: 0xc0000005
Fault offset: 0x00000000000195e7
Faulting process id: 0x640
Faulting application start time: 0x01ce578d1972b399
Faulting application path: C:\Users\Wasi\Documents\Tools\CoreTemp64\Core Temp.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 91ddaa68-c3a7-11e2-bebf-00248ca1b4ce
Faulting package full name: 
Faulting package-relative application ID:

Which is very worrying...

I've tried sfc /scannow to no avail. Windows updated one of my drivers (ATK0110) to a newer version so I rolled back and rebooted. No luck. I can't think of anything else that has changed in the past few days. Not getting BSODs currently, just these crashes.

Also, I tested on my laptop and can absolutely not reproduce the MPC-HC crash, even with the same media files (the crash happens with various files so it isn't file-specific)

I've also tried underclocking CPU and RAM but this did not help.

Any help would be appreciated and I will definitely give more info if necessary

Thank you

Specs:
Asus P6T standard motherboard (BIOS 1408)
Corsair Vengeance 12GB
Zotac Geforce GTX 670 2GB
OCZ Agility 3 120GB SSD
Seagate 1TB HDD
Corsair TX750 750 Watt PSU
i7 920 D0


----------



## Satanas

For some reason I cannot edit my post, so I apologize for the double post

I just wanted to add that I have tried a Clean Boot (disable all non-MS services and disable all startup items) and this made no difference.


----------



## Satanas

An update

I've ran 24h30m of Memtest86+ 4.2 and had 13 successful passes with no errors, so I'm thinking this is probably not RAM-related as I would have perhaps thought.

I am aware that you guys probably don't have enough information to debug this but since the error is extremely easy for me to reproduce, how would I go about collecting a dump or log of the appcrash that you guys could take a look at? Let me know and I will provide the necessary information. The crashing is quite consistent and distressing and I hope it can be solved.

Thank you for any help


----------



## VirGnarus

You could get it to create crashdumps using this. However, I'm not sure that will help. The error codes means heap memory (that's memory used by applications and stuff) is getting corrupted. The applications crashing are most likely not the ones corrupting the heap as well.

About the most surefire way to do this is to follow the instructions given above to enable crashdump generation from applications, and then use gflags. You can get gflags by downloading _Debugging Tools_ from the Windows WDK 8. Once done, you'll need to initially navigate to gflags. Most likely it'll be in _C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\gflags.exe_. With it open, select only in _System Registry_ tab the following:

* Enable heap tail checking
* Enable heap free checking
* Enable heap parameter checking
* Enable heap validation on call

*NOTE:* These settings may or may not cause your system to crawl or reach an unstable state, and may even affect Safe Mode to that amount. I recommend setting up a System Restore point prior to doing this.

Restart your computer after clicking "Apply" then "OK" on gflags. If all goes well, your system will at least be responsive enough for you to try and run one of the problematic applications. If it crashes, the settings you made prior to have it produce a crashdump should go into effect. Provide us said crashdumps.


----------



## Satanas

Thanks very much for taking the time to reply

I was able to solve the problem once I determined the error was related to heap corruption and access violations. Since it wasn't a RAM problem, and it didn't appear to be a driver problem, I ran the latest version of CCleaner's registry tool and cleaning up the registry actually resulted in this error becoming impossible to reproduce.

Now, I do have a question in regards to that. A couple days prior I was experimenting with an overclock which resulted in a few inevitable BSODs while I was tweaking the voltages. Is it possible that during those BSODs my registry became corrupted? Asking purely out of curiosity, as the issue itself is now solved

Thanks again. If anyone else has similar issues I'd say CCleaner has a pretty powerfully good registry tool.


----------



## Satanas

*Re: [SOLVED] App crashing - 0xc0000374 and 0xc0000005 exception code*

UPDATE

The problem recurred after the registry cleaning so I did some investigation.

We used AutoHotKey to open a file in MPC and close MPC 200 times. Doing so with Logitech Gaming Software 8.46 installed always resulted in a crash with one of the above exception codes within the first 20 tries. With it uninstalled, or with an older version, no such behaviour was observed in over 400 tries.

The conclusion is - don't use LGS 8.46, it causes heap corruption.


----------



## VirGnarus

*Re: [SOLVED] App crashing - 0xc0000374 and 0xc0000005 exception code*

That's one brute force way of finding an answer! How'd you narrow it down to testing the Logitech software anyways? Just trial and error with uninstalling each software?

I also would advise against _any_ registry cleaning of any kind, even with CCleaner. They operate on a best guess basis and have had a propensity to cause more harm than good. I have yet to find anyone that's a professional troubleshooter that does not recommend avoiding such an operation. If you wish to use CCleaner, use its safer options like cleaning misc files and whatnot, but avoid the registry portion, as tempting it may be.

Btw, heap corruption can easily be caused by RAM problems, and it can also be caused by drivers as drivers can operate with their usermode applications by altering contents in the heap. Just throwing that out there for clarification.


----------



## Satanas

*Re: [SOLVED] App crashing - 0xc0000374 and 0xc0000005 exception code*



VirGnarus said:


> That's one brute force way of finding an answer! How'd you narrow it down to testing the Logitech software anyways? Just trial and error with uninstalling each software?
> 
> I also would advise against _any_ registry cleaning of any kind, even with CCleaner. They operate on a best guess basis and have had a propensity to cause more harm than good. I have yet to find anyone that's a professional troubleshooter that does not recommend avoiding such an operation. If you wish to use CCleaner, use its safer options like cleaning misc files and whatnot, but avoid the registry portion, as tempting it may be.
> 
> Btw, heap corruption can easily be caused by RAM problems, and it can also be caused by drivers as drivers can operate with their usermode applications by altering contents in the heap. Just throwing that out there for clarification.


I agree with your comment about registry cleaners in general. That was a last-ditch effort (in the sense that I was ready to reinstall Windows if it did not work, but I made a registry backup just in case).

When that didn't solve the problem I simply mentally tried to recall my most recent driver installations. Other than the ATK0110 driver, the only thing I could think of was that I had updated Logitech Gaming Software to 8.46 less than 10 days ago, and that running a Clean Boot would not prevent the mouse/kb drivers from actually loading.

So using auto-hotkey, I was able to confirm that uninstalling these drivers/installing the older version solves this heap corruption issue, thus leading me to believe that Logitech's latest drivers are simply something I recommend avoiding.

As far as RAM goes, this was my first suspicion. But over 24 hours of Memtest86+ yielded no issues and so I was relatively sure such an easy to replicate issue was likely caused by something other than the RAM

Thanks for your comments and help


----------



## VirGnarus

*Re: [SOLVED] App crashing - 0xc0000374 and 0xc0000005 exception code*

Alright, glad to hear it. We'll keep a watch out for any similar instances regarding this Logitech software.


----------



## Satanas

Regrettably this issue is still occurring! It is very inconsistent and hard to pin down, and it is driving me crazy...

So the issue seems to not be caused by the Logitech driver I suppose, since it still occurs without it.

I am going to install the WDK as you suggested as soon as I can and try to provide you some crash dumps. Thanks so much for your help so far.

Edit: Just so I know, where will I be able to find the crashdump needed after enabling gflags?


----------



## VirGnarus

That's specified in the article, under the _DumpFolder_ registry value that you can set to your own specifications. Default is _%LOCALAPPDATA%/CrashDumps_, where _%LOCALAPPDATA%_ is where the AppData for that application is usually stored (commonly _C:/Users/Youraccounthere/AppData). It's a hidden folder so you'll need to make sure your folder options are set to reveal hidden folders. Or, of course, you can just change it to whatever you like._


----------



## Satanas

Ok thanks for the clarification. Following those instructions I have enabled "MiniDump" - is this what I should have enabled? Or should I have enabled full?

I rebooted with the gflags settings ticked and as you predicted the computer is booting immensely slowly, but it seems to be doing something so I'll try to get to a state where I can generate at least one crash even if it takes forever

Please let me know if I need a full dump instead of mini, hopefully mini was the correct choice (this was the default choice for dump type)

Thank you. Will update once I have successfully generated a crash, hopefully I can with this immense slowdown


----------



## Satanas

The computer has been booting for about 1.5 hours. I'm hoping if I leave it on overnight it'll be in a usable state by morning...


----------



## VirGnarus

I highly recommend Full dump. 

If the system is taking that slow to boot, I recommend going into Safe Mode and disabling Heap parameter checking and Validation on call. That should speed things up. It won't be as paranoid in the event of something erroneous occurs, but I believe the tail and free checking should be enough for us to get by for now.


----------



## Satanas

I went into msconfig and enabled safe mode and tried to reboot. The reboot process stayed at "installing 1 of 1 updates" for many hours so I manually rebooted using the button. Now I hang after the Windows 8 logo sequence at a black screen indefinitely. I also cannot figure out how to get into safe mode. Mashing F8 or Shift+F8 at the bios screen simply brings up boot device selection, and if I mash beyond that nothing happens, it just attempts to boot normally...

Ok was finally able to get into safe mode. Will switch to full dumps and disable those two things and reboot, then try to get the crash to generate. Thanks

Update: an annoying side effect of this is that (whether safe mode or not) my mouse pointer is not visible. Also, while in safe mode a dialog box keeps appearing saying "explorer.exe - unknown hard error" and I can't seem to do anything. Unfortunately it appears as though I can't do anything. I can't bring up the start menu, run command, or pretty much get anything to generate other than the black desktop with nothing on it


----------



## Satanas

Update 2:
After a ton of struggle I managed to initiate a system restore. I hope it works. Will keep you up to date.

Afterwards I'll try full dump + only two gflags options set.


----------



## Satanas

Was able to generate a crash with the following settings:

- FULL Dump
- Enable heap tail checking
- Enable heap free checking

The file has been uploaded to ge.tt here in a 7zip archive ( full link: ge.tt/7AJdOZi/v/0?c )

Thanks very much for all of your help. If you need more crashes I can generate them fairly easily with these settings, it was the Validation on call/Parameter checking that was making my system unusable.


----------



## VirGnarus

I'll take a look at this. If this doesn't work, we can disable these options and try the other two.


----------



## Satanas

VirGnarus said:


> I'll take a look at this. If this doesn't work, we can disable these options and try the other two.


Thanks so much for your continued help. I hope we can find the cause of this


----------



## VirGnarus

It doesn't appear that the crash occurred at the right time. I'm not sure if this will provide us an accurate solution, so we may have to try again with the other two gflags this time.

However, I did get some more information this time around due to the crashdump. Here are the modules/codecs involved:


madHcNet.dll*
LAVVideo.ax
avcodec-lav-55.dll
VSFilter.dll
MVRSETTINGS.DLL
madVR.ax
ReCLock.dll
Resampler.dll
LAVSplitter.ax

* - one tagged as responsible for crash.

MadHcNet.dll is part of the MadVR video renderer. Again, this is the item that tripped up on the bad heap. I'm not entirely sure it's responsible for causing said heap issue. Nevertheless, it may be good to remove it for now.

Btw, have you considered uninstalling the Kawaii Codec Pack? There's a lot more in it than just codecs, and it seems there may be conflicting issues with it.


----------



## Satanas

VirGnarus said:


> It doesn't appear that the crash occurred at the right time. I'm not sure if this will provide us an accurate solution, so we may have to try again with the other two gflags this time.
> 
> However, I did get some more information this time around due to the crashdump. Here are the modules/codecs involved:
> 
> 
> madHcNet.dll*
> LAVVideo.ax
> avcodec-lav-55.dll
> VSFilter.dll
> MVRSETTINGS.DLL
> madVR.ax
> ReCLock.dll
> Resampler.dll
> LAVSplitter.ax
> 
> * - one tagged as responsible for crash.
> 
> MadHcNet.dll is part of the MadVR video renderer. Again, this is the item that tripped up on the bad heap. I'm not entirely sure it's responsible for causing said heap issue. Nevertheless, it may be good to remove it for now.
> 
> Btw, have you considered uninstalling the Kawaii Codec Pack? There's a lot more in it than just codecs, and it seems there may be conflicting issues with it.


Interestingly I have tried installing different versions of KCP, the issue being that on my previous Windows 8 install that I never had any issues like this with said player, nor do either of my other two PCs (all use the same version currently).

Another thing that might be interesting to note is that if I use MPC-HC's "open file" dialog (where you enter a path to the file you wish to open) and then play it, it will seemingly never crash (this is why AutoHotKey never generated a crash in over 400 tries). But if I use the "Quick Open" dialog which opens up a Folder Browser dialog to select the file, and select it from there, upon open it seems to crash within 20 tries or less (sometimes the first try). I've also experienced 0x374 crashes while browsing randomly in Windows Explorer but these are rare and difficult to reproduce, and I will not likely be able to generate one of those crashes.

Should I try again with the other options selected?

*Speak of the devil, Explorer.exe just crashed.* Will upload the DMP as soon as possible

The DMP file is pretty big, 170MB zipped size, so I'll post again with a link when it is complete. Thank you for your continued help


----------



## Satanas

*Explorer.exe crash while file browsing randomly*:

explorer.exe.3960.7z


----------



## VirGnarus

Ok this is strange.

First of all, I'm not 100% sure this is the culprit, and it feels more like another victim to someone that has already tampered with heap they're not supposed to be tampering with. Nevertheless, I'll mention the two modules present in this case:


googledrivesync64*
DropboxExt64.19.dll

* - tagged as cause of crash.

In this case, it almost seems as if Google Sync and Dropbox are conflicting with each other.

The oddest thing about this, however, is in the previous crashdump you gave me, it said Windows 8 was the x86 (32-bit) version, but in this crashdump, it says it's Windows 8 64-bit. I don't think I've ever seen this before, nor do I understand why it's just deciding to switch between the two versions for no good reason. I don't think it's WOW64 kicking in, because I believe I would see that here. Maybe I'm misinterpreting things, dunno. But it does seem very, very strange to me.

Btw, the other two gflags? Scratch em. Instead, keep the current two gflags on (free and tail checking), and also enable page heap under the same Kernel Flags tab. This is the item that is most likely to give us some clear answer in conjunction with the other two. Understand that this will most likely considerably increase memory usage.


----------



## Satanas

VirGnarus said:


> Ok this is strange.
> 
> First of all, I'm not 100% sure this is the culprit, and it feels more like another victim to someone that has already tampered with heap they're not supposed to be tampering with. Nevertheless, I'll mention the two modules present in this case:
> 
> 
> googledrivesync64*
> DropboxExt64.19.dll
> 
> * - tagged as cause of crash.
> 
> In this case, it almost seems as if Google Sync and Dropbox are conflicting with each other.
> 
> The oddest thing about this, however, is in the previous crashdump you gave me, it said Windows 8 was the x86 (32-bit) version, but in this crashdump, it says it's Windows 8 64-bit. I don't think I've ever seen this before, nor do I understand why it's just deciding to switch between the two versions for no good reason. I don't think it's WOW64 kicking in, because I believe I would see that here. Maybe I'm misinterpreting things, dunno. But it does seem very, very strange to me.
> 
> Btw, the other two gflags? Scratch em. Instead, keep the current two gflags on (free and tail checking), and also enable page heap under the same Kernel Flags tab. This is the item that is most likely to give us some clear answer in conjunction with the other two. Understand that this will most likely considerably increase memory usage.


That's a very bizarre thing to be happening, but yes the current Windows version is 8 x64 Pro. Hm.

Google drive sync and dropbox eh? Interesting. If need be I will remove both, however for now I've enabled "Enable page heap" under "Kernel Flags" (This option also exists under "System Registry" but I've left this one blank and only enabled the one under "Kernel Flags", hopefully that's correct?)

I'll try to generate more crashdumps through using MPC's folder browser to load files as this is by far the easiest way to generate a crash. "Hopefully" I can generate an explorer crash, and I'll definitely let you know if I do, but it is a rather rare occurrence and I might not have too much luck with it

Thanks so much for the continued assistance, it is greatly appreciated. Hopefully Page Heap increases memory usage (which is fine, as this system has a lot of memory) without slowing down the PC as much as those other options. Will report back with new crashes when I can


----------



## Satanas

*Just a question regarding Enable page heap*

So I've enabled this under Kernel Flags, and then rebooted. However, when I open gflags after the reboot, the option is now deselected. Am I supposed to enable it, apply and then _not _restart? I'm a bit confused.

Also, strangely, enabling Page heap seems to cause Google Chrome to not load any websites and I can only use IE when it's enabled. Not a major concern, really, but definitely peculiar.

Let me know as soon as you can -- thank you!


----------



## Satanas

Hey VirGnarus,

Explorer.EXE crashed again today and I have a link to the new dump, but unfortunately I believe "Enable page heap" WAS NOT enabled, as it seems that if I enable this and then reboot that it then disables itself. Is this the case? If so, should I enable it, _not _reboot, and then try to provide an additional crash?

In any case I have uploaded the new crash here in case it contains anything useful:
explorer.exe.3832.dmp.7z

Let me know about the "Enable page heap" when you can and I will try to get a crash with that option enabled properly. Thank you so much for your continued help.


----------



## VirGnarus

Sorry, I won't be able to work on this until next week. Got a lot on my plate right now. Pardon!


----------



## Satanas

VirGnarus said:


> Sorry, I won't be able to work on this until next week. Got a lot on my plate right now. Pardon!


Not an issue. I'll watch for updates to this thread next week. Thanks.


----------



## VirGnarus

Ok I'm back. Yeah, GoogleSync is rearing its ugly head again in this one too. I'm getting a bit more confident that it's the root cause since it appears it's freeing memory, which that memory is getting checked and discovering that there's some corruption that's occurred. I'd take care of that first.

Btw, a big ole DOH! moment on my part. The Kernel flags in Gflags actually affect the environment immediately but are _lost on reboot_. The _System registry_ flags are the ones that persist across reboots. I got the two all mixed up! So no wonder it was disappearing after a reboot.

If you are still persistent, we can enable page heap again on Kernel flags and keep the system running until the appcrash then send us the crashdump.

Oh, and just so you know, after enabling page heap and whatnot on the Kernel flags tab, they only affect allocations/frees made _after_ enabling it. It is not retroactive. If you want the system to watch all heap allocations, you'll want to enable the proper settings in the System Registry flags instead and reboot.


----------



## Satanas

VirGnarus said:


> Ok I'm back. Yeah, GoogleSync is rearing its ugly head again in this one too. I'm getting a bit more confident that it's the root cause since it appears it's freeing memory, which that memory is getting checked and discovering that there's some corruption that's occurred. I'd take care of that first.
> 
> Btw, a big ole DOH! moment on my part. The Kernel flags in Gflags actually affect the environment immediately but are _lost on reboot_. The _System registry_ flags are the ones that persist across reboots. I got the two all mixed up! So no wonder it was disappearing after a reboot.
> 
> If you are still persistent, we can enable page heap again on Kernel flags and keep the system running until the appcrash then send us the crashdump.
> 
> Oh, and just so you know, after enabling page heap and whatnot on the Kernel flags tab, they only affect allocations/frees made _after_ enabling it. It is not retroactive. If you want the system to watch all heap allocations, you'll want to enable the proper settings in the System Registry flags instead and reboot.


I will likely try generating and uploading the crash through enabling the System Registry flags just to be sure. I'll upload a crash at some point tomorrow when I can. It will probably be a crash from the media player since the explorer crashes are difficult to generate, but hopefully it will tell us something.

Thanks!


----------



## Satanas

Ok so an update on this. Enabling page heap and rebooting makes my computer act bizarre - Google Chrome can't load any pages, and MPC simply hangs while trying to open any file, which does not end up generating a crash dump (just an application not responding).

Any ideas? In any case, the issue seems to be somewhat avoidable if I just load media files through windows explorer rather than via the File Browser in MPC. If it gets annoying later I might just get rid of Google Drive.

Thanks for the help so far. If any further ideas let me know, otherwise for now we can put this issue aside and I'll report back if anything gets worse / anything else becomes affected.


----------



## VirGnarus

Hmm, it means we're getting somewhere, but that's not the behavior I expected. If you can, while MPC hangs, open Process Explorer, find the MPC process, right click it and have a Full dump created from it. Zip it up and upload to some site like Mirrorcreator.com.

If you want, you can do the same for Google Chrome as it fails to load a page.


----------



## Satanas

VirGnarus said:


> Hmm, it means we're getting somewhere, but that's not the behavior I expected. If you can, while MPC hangs, open Process Explorer, find the MPC process, right click it and have a Full dump created from it. Zip it up and upload to some site like Mirrorcreator.com.
> 
> If you want, you can do the same for Google Chrome as it fails to load a page.


Will try this as soon as I can, but I have a question regarding getting the full dump creation. If Chrome fails to load a page, can I simply go and create the dump while it is stalling? It just sits there infinitely loading the page, it doesn't go into a "This program is not responding" / greyed out state.

MPC I can probably get into a "This program is not responding" state, though.

Thanks!


----------

