Windows Repeatedly Crashing

Hello All,

I purchased a new computer about 2 months ago, and since the day I started using it, have had more problems than I can count. At first, the computer would run fine for an hour or so, and then I would get a BSOD with different error codes almost every time. After a few days of this, it started crashing more often and pretty soon, I wasn't able to use the computer at all because it would crash immediately upon booting the computer. I called Microsoft support, and they sent me a disc for a fresh installation of Windows 8, and it solved the issues for a few days, then began acting up again. In the past few days, it has gotten so bad that I can barely use the computer. Programs crash all the time, and often I have to restart my computer multiple times to even be able to use it for a few minutes. I get BSOD's extremely often, and have done everything I can, to no avail. Here is a link to the computer so you can see the specs and technical details:

If you guys can help me in any way, I would appreciate it so much. I know you guys will want error logs and such, but I'm not sure where to find them, so if you could also help me in that aspect, I would be grateful.

Thanks in advance for the help.



Thanks very much!

We have various bug checks:


This indicates that a severe memory management error occurred.

BugCheck 1A, {41284, fffff6805a9e6001, 1f5b3, fffff70001080000}

- The 1st parameter of the bug check is 41284 which indicates a PTE or the working set list is corrupted.

0: kd> dt nt!_MMPFN fffff6805a9e6001
   +0x000 u1               : <unnamed-tag>
   +0x008 u2               : <unnamed-tag>
   +0x010 PteAddress       : (null)
   +0x010 VolatilePteAddress : (null)
   +0x010 Lock             : 0n0
   +0x010 PteLong          : 0
   +0x018 u3               : <unnamed-tag>
   +0x01c NodeBlinkLow     : 0
   +0x01e Unused           : 0y0000
   +0x01e VaType           : 0y0000
   +0x01f ViewCount        : 0 ''
   +0x01f NodeFlinkLow     : 0 ''
   +0x020 OriginalPte      : _MMPTE
   +0x028 u4               : <unnamed-tag>

^^ All zeroed out, indicating it is indeed corrupted (either by a driver or faulty RAM).


This indicates that a system thread generated an exception which the error handler did not catch.

BugCheck 1000007E, {ffffffffc0000005, fffff802bf2e21b0, fffff88009cd1768, fffff88009cd0fa0}

^^ The 1st parameter of the bug check is 0xc0000005 which indicates that an access violation has occurred.

4: kd> .exr 0xfffff88009cd1768
ExceptionAddress: fffff802bf2e21b0 (nt!ExFreePoolWithTag+0x0000000000000050)
   ExceptionCode: c0000005 (Access violation)

^^ The violation occurred in nt!ExFreePoolWithTag. This routine deallocates a block of pool memory allocated with the specified tag.


This indicates that an exception happened while executing a routine that transitions from non-privileged code to privileged code.

This error has been linked to excessive paged pool usage and may occur due to user-mode graphics drivers crossing over and passing bad data to the kernel code.

BugCheck 3B, {c0000005, fffff801ce29dfdc, fffff880094ecc50, 0}

2: kd> ln fffff801ce29dfdc
(fffff801`ce29dc90)   nt!ObpCreateHandle+0x34c   |  (fffff801`ce29e5a0)   nt!AlpcpReceiveMessagePort

^^ The exception occurred in nt!ObpCreateHandle.


This indicates that the kernel has detected critical kernel code or data corruption.

There are generally two causes for this bug check:

  1. A driver has inadvertently, or deliberately, modified critical kernel code or data. Microsoft Windows Server 2003 with Service Pack 1 (SP1) and later versions of Windows for x64-based computers do not allow the kernel to be patched except through authorized Microsoft-originated hot patches. For more information, see Patching Policy for x64-based Systems.
  2. A hardware corruption occurred. For example, the kernel code or data could have been stored in memory that failed.


1. Uninstall all CyberLink software.

2. I see HackShield drivers in the modules list, however they are unlisted, so I am unsure as to whether or not it's truly installed. Regardless, if HackShield is still installed, please uninstall ASAP.

3. If you're still crashing after all of the above, we likely have a memory issue. However, before running RAM diagnostics, please enable Driver Verifier to be sure there are no low-level drivers causing corruption:

Driver Verifier:

What is Driver Verifier?

Driver Verifier is included in Windows 8/8.1, 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008, Windows 2000, Windows XP, and Windows Server 2003 to promote stability and reliability; you can use this tool to troubleshoot driver issues. Windows kernel-mode components can cause system corruption or system failures as a result of an improperly written driver, such as an earlier version of a Windows Driver Model (WDM) driver.

Essentially, if there's a 3rd party driver believed to be at issue, enabling Driver Verifier will help flush out the rogue driver if it detects a violation.

Before enabling Driver Verifier, it is recommended to create a System Restore Point:

Vista - START | type rstrui - create a restore point
Windows 7 - START | type create | select "Create a Restore Point"
Windows 8/8.1 -

How to enable Driver Verifier:

Start > type "verifier" without the quotes > Select the following options -

1. Select - "Create custom settings (for code developers)"
2. Select - "Select individual settings from a full list"
3. Check the following boxes -
- Special Pool
- Pool Tracking
- Force IRQL Checking
- Deadlock Detection
- Security Checks (Windows 7 & 8)
- DDI compliance checking (Windows 8)
- Miscellaneous Checks
4. Select  - "Select driver names from a list"
5. Click on the "Provider" tab. This will sort all of the drivers by the provider.
6. Check EVERY box that is NOT provided by Microsoft / Microsoft Corporation.
7. Click on Finish.
8. Restart.

Important information regarding Driver Verifier:

- If Driver Verifier finds a violation, the system will BSOD. To expand on this a bit more for the interested, specifically what Driver Verifier actually does is it looks for any driver making illegal function calls, causing memory leaks, etc. When and/if this happens, system corruption occurs if allowed to continue. When Driver Verifier is enabled, it is monitoring all 3rd party drivers (as we have it set that way) and when it catches a driver attempting to do this, it will quickly flag that driver as being a troublemaker, and bring down the system safely before any corruption can occur.

- After enabling Driver Verifier and restarting the system, depending on the culprit, if for example the driver is on start-up, you may not be able to get back into normal Windows because Driver Verifier will detect it in violation almost straight away, and as stated above, that will cause / force a BSOD.

If this happens, do not panic, do the following:

- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.

- Once in Safe Mode - Start > Search > type "cmd" without the quotes.

- To turn off Driver Verifier, type in cmd "verifier /reset" without the quotes.
・    Restart and boot into normal Windows.

If your OS became corrupt or you cannot boot into Windows after disabling verifier via Safe Mode:

- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.

- Once in Safe Mode - Start > type "system restore" without the quotes.

- Choose the restore point you created earlier.

-- Note that Safe Mode for Windows 8/8.1 is a bit different, and you may need to try different methods: 5 Ways to Boot into Safe Mode in Windows 8 & Windows 8.1

How long should I keep Driver Verifier enabled for?

I recommend keeping it enabled for at least 24 hours. If you don't BSOD by then, disable Driver Verifier. I will usually say whether or not I'd like for you to keep it enabled any longer.

My system BSOD'd with Driver Verifier enabled, where can I find the crash dumps?

They will be located in %systemroot%\Minidump

Any other questions can most likely be answered by this article:



Debugger/Reverse Engineer.

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.


In order to assist you, we will need the .DMP files to analyze what exactly occurred at the time of the crash, etc.

If you don't know where .DMP files are located, here's how to get to them:

1. Navigate to the %systemroot%\Minidump folder.

2. Copy any and all DMP files in the Minidump folder to your Desktop and then zip up these files.

3. Upload the zip containing the .DMP files to Onedrive or a hosting site of your choice and paste in your reply. Prefered sites: Onedrive, Mediafire, Dropbox, etc. Nothing with wait-timers.

4 (optional): The type of .DMP files located in the Minidump folder are known as Small Memory Dumps. In %systemroot% there will be what is known as a Kernel-Dump (if your system is set to generate). It is labeled MEMORY.DMP. The difference between Small Memory Dumps and Kernel-Dumps in the simplest definition is a Kernel-Dump contains much more information at the time of the crash, therefore allowing further debugging of your issue. If your upload speed permits it, and you aren't going against any strict bandwidth and/or usage caps, etc, the Kernel-Dump is the best choice. Do note that Kernel-Dumps are much larger in size due to containing much more info, which is why I mentioned upload speed, etc.

If you are going to use Onedrive but don't know how to upload to it, please visit the following:

Upload photos and files to Onedrive.

Please note that any "cleaner" programs such as TuneUp Utilities, CCleaner, etc, by default will delete .DMP files upon use.

If your computer is not generating .DMP files, please do the following:

1. Start > type %systemroot% which should show the Windows folder, click on it. Once inside that folder, ensure there is a Minidump folder created. If not, CTRL-SHIFT-N to make a New Folder and name it Minidump.

2. Windows key + Pause key. This should bring up System. Click Advanced System Settings on the left > Advanced > Performance > Settings > Advanced > Ensure there's a check-mark for 'Automatically manage paging file size for all drives'.

3. Windows key + Pause key. This should bring up System. Click Advanced System Settings on the left > Advanced > Startup and Recovery > Settings > System Failure > ensure there is a check mark next to 'Write an event to the system log'.

Ensure Small Memory Dump is selected and ensure the path is %systemroot%\Minidump.

4. Double check that the WERS is ENABLED:

Start > Search > type services.msc > Under the name tab, find Windows Error Reporting Service > If the status of the service is not Started then right click it and select Start. Also ensure that under Startup Type it is set to Automatic rather than Manual. You can do this by right clicking it, selecting properties, and under General selecting startup type to 'Automatic', and then click Apply.

If you cannot get into normal mode to do any of this, please do this via Safe Mode.


Debugger/Reverse Engineer.

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.


Question Info

Last updated March 24, 2018 Views 356 Applies to: