[SOLVED] BSOD After Switching to 8.1

Kramer III

Member
Joined
Jun 1, 2014
Posts
8
Location
Boulder, CO
Hello,

Since switching to Windows 8.1, my computer crashes fairly frequently. Before switching I had no problems. I rather like 8.1 though and would prefer to keep it. It seems to happen more quickly when running any program, but will also happen when the computer is idle. If left alone, it crashes every 13-15 minutes. However, every so often it will run flawlessly, never crashing. I tried fixing it with the help of Windows professional support throughout January, though nothing seemed to help. I didn't have enough time to keep trying during the school year, so whenever it would run without crashing I had to leave it on for as long as possible.

While running
BSOD_Windows7_Vista_v2.64_jcgriff2_ my computer crashed once, and the program locked up the second time. Hopefully the files are still complete. Additionally, I get an error "The operator or administrator has refused the request" when running the resource and performance monitor. I'm certain I'm running it as an administrator as well.


· Windows 8.1

· x64
· Originally Windows 7
· 8.1 acquired from my university
· Computer built April 2013
· 8.1 installed in December 2013, re-installed in January 2014

· Intel Core i5-3570K 3.4 GHz
· Radeon HD 7870
·
ASRock Z77 Extreme4
· Rosewill Capstone-750-M 750W

· Custom built desktop

Let me know what needs to be done!

Thanks
View attachment 8151
 
Hi,

All of the attached DMP files are of the MEMORY_MANAGEMENT (1a) bug check.

This indicates that a severe memory management error occurred.

Code:
BugCheck 1A, {[COLOR=#ff0000]41792[/COLOR], fffff68030cc1248, 20000000000000, 0}

- The 1st parameter of the bug check is 41792 which indicates a corrupted PTE has been detected.

Code:
2: kd> dt nt!_MMPFN fffff68030cc1248
   +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>

Code:
Probably caused by : memory_corruption ( [COLOR=#ff0000]ONE_BIT[/COLOR] )

It's ONE_BIT corruption, so it's likely faulty RAM as opposed to a 3rd party driver causing corruption. To be sure though, please run Driver Verifier first:


Driver Verifier:

What is Driver Verifier?

Driver Verifier monitors Windows kernel-mode drivers, graphics drivers, and even 3rd party drivers to detect illegal function calls or actions that might corrupt the system. Driver Verifier can subject the Windows drivers to a variety of stresses and tests to find improper behavior.

Essentially, if there's a 3rd party driver believed to be causing the issues at hand, enabling Driver Verifier will help us see which specific driver is causing the problem.

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 - Restore Point - Create in Windows 8

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/8.1)
- DDI compliance checking (Windows 8/8.1)
- 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 per my instructions above, 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?

- If you have the system set to generate Small Memory Dumps, they will be located in %systemroot%\Minidump.

- If you have the system set to generate Kernel-Memory Dumps, it will be located in %systemroot% and labeled MEMORY.DMP.

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

Using Driver Verifier to identify issues with Windows drivers for advanced users

Regards,

Patrick
 
No good, unfortunately. It's 0x1A again with ONE_BIT.

With that said, time for Memtest:

Memtest86+:

Download Memtest86+ here:

Memtest86+ - Advanced Memory Diagnostic Tool

Which should I download?

You can either download the pre-compiled ISO that you would burn to a CD and then boot from the CD, or you can download the auto-installer for the USB key. What this will do is format your USB drive, make it a bootable device, and then install the necessary files. Both do the same job, it's just up to you which you choose, or which you have available (whether it's CD or USB).

Do note that some older generation motherboards do not support USB-based booting, therefore your only option is CD (or Floppy if you really wanted to).

How Memtest works:

Memtest86 writes a series of test patterns to most memory addresses, reads back the data written, and compares it for errors.

The default pass does 9 different tests, varying in access patterns and test data. A tenth test, bit fade, is selectable from the menu. It writes all memory with zeroes, then sleeps for 90 minutes before checking to see if bits have changed (perhaps because of refresh problems). This is repeated with all ones for a total time of 3 hours per pass.

Many chipsets can report RAM speeds and timings via SPD (Serial Presence Detect) or EPP (Enhanced Performance Profiles), and some even support changing the expected memory speed. If the expected memory speed is overclocked, Memtest86 can test that memory performance is error-free with these faster settings.

Some hardware is able to report the "PAT status" (PAT: enabled or PAT: disabled). This is a reference to Intel Performance acceleration technology; there may be BIOS settings which affect this aspect of memory timing.

This information, if available to the program, can be displayed via a menu option.

Any other questions, they can most likely be answered by reading this great guide here:

FAQ : please read before posting

Regards,

Patrick
 
It also looks like my computer isn't going to crash until it's restarted again. If anything needs to be done that relies on it running for more than 15 minutes straight, now is the time to do it.
 
Tanks!

Well, it's an 0x1A again, and with verifier enabled, it's -

Code:
FAILURE_BUCKET_ID:  MEMORY_CORRUPTION_ONE_BIT

again...

Looks like regardless of passing Memtest you have faulty RAM, or bad DIMM slots on the board. To troubleshoot possible bad DIMM slots, you'll have to test your sticks in different slots, and perhaps one at a time.

I'd update the BIOS also if available.

Regards,

Patrick
 
Testing the slots and RAM is easy enough so I'll try that first. I've heard that updating BIOS is not as simple as most software. Do you have any advice on how to do that?
 
That's a huge myth. Updating the BIOS is as simple as unzipping a .RAR to get the .ROM file on the thumb drive, and then you update the BIOS, generally from within the BIOS. I absolutely 100% do not ever recommend updating the BIOS with software, ever. Always update directly through the BIOS if possible.

Regards,

Patrick
 
Appears to be a faulty RAM stick! Tried all combinations, one of the two didn't even allow the computer to start. I've restarted 10+ times now with no crashes. Suppose that shows that Memtest isn't perfect. Thanks for all your help!
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top