Take the 2-minute tour ×

When logging into Windows 7 today, my PC instantly BSOD'd. Using WhoCrashed I get the following report:


  • On Tue 12.02.2013 13:56:20 GMT your computer crashed
  • crash dump file: C:\Windows\Minidump\021213-27390-01.dmp
  • uptime: 00:00:25
  • This was probably caused by the following module: ntoskrnl.exe (nt+0x1AA698)
  • Bugcheck code: 0x1000007E (0xFFFFFFFFC0000096, 0xFFFFF80003610698, 0xFFFFF8800614C7B8, 0xFFFFF8800614C010)
  • file path: C:\Windows\system32\ntoskrnl.exe
  • product: Microsoft® Windows® Operating System
  • company: Microsoft Corporation
  • description: NT Kernel & System
  • Bug check description: This indicates that a system thread generated an exception which the error handler did not catch.



Now, my PC had been crashing/freezing occasionally and on specific performance-heavy tasks in the past, but the cause of it (I thought) was a flawed RAM-slot in my motherboard. Keeping that slot empty stopped the crashes.

Today, it crashed again, and I have not changed anything hardware-related.

I know I could go around Google reading what this bugcheck code means, but lately I've come to realize that a personal experience from somebody (with the same bugcheck/problem) is much more useful, specially as this person might have come to a solution.

Thank you very much!

share|improve this question
First...Update all your device drivers. Use safe mode to adjust what drivers are loaded when Windows is loaded –  Ramhound Feb 12 '13 at 14:34
Thank you! In regards to my answer to Ian Boyd, would you happen to know of a good device-updating software? Or is the usual manual-method still the best for updating your driver(s)? –  cr0z3r Feb 12 '13 at 14:48
Any software designed to update your drivers ( except Windows Update ) is a huge scam. Do it the correct way yourself –  Ramhound Feb 12 '13 at 17:13
add comment

1 Answer

up vote 9 down vote accepted

In this case, a thread encountered the exception

          Executing an instruction not allowed in current machine mode.

This error was raised by the CPU itself. Some code tried to execute an instruction that it isn't allowed to do. Likely this is caused by memory corruption; where kernel code tried to execute junk data.

This kind of error really is impossible to pinpoint. There was an error in "kernel" code that shouldn't have happened. It's extraordinarily unlikely that there's a software bug in any of Microsoft's code; which is when you begin to look elsewhere.

  • Third Party Drivers. Kernel mode drives have full access to the physical hardware. Any stray bug in any 3rd party driver (e.g. video, sound, network, USB 3.0, SATA) and it can corrupt code or data of anything else in the system. Next steps: try removing newly added hardware (so some third party drivers are not loaded), try booting in safe mode (so some third party drivers are not loaded), or reinstall Windows (so some 3rd party drivers are not loaded)
  • Bad RAM. If a bit was flipped, and it turned a perfectly benign instruction into a different, invalid, instruction, you could get this error. Next Steps: Remove RAM stick, move RAM to other slots, unclock RAM, change power supplies
  • Overclocking. Sometimes extraordinarily strange things can happen when you overclock. Hopefully everyone is sending Microsoft their crash dumps; because Microsoft does investigate them. A common error they would get is when the CPU is executing the instruction:

    xor eax, eax;

    This is an extraordinarily simple operation that the CPU can execute; it's simply setting an internal CPU register EAX to zero. There's no way it can fail; except when you overclock - or other physical problems.

tl;dr: If you've eliminated the software, then it's the hardware.

Update: Troubleshooting Methodology

i wanted to mention the details that i went through, almost mindlessly when looking at this error.

The first was the actual bugcheck code:


Binging that on Google gives the Microsoft documentation page



i know, from experience being a developer, that if my application (or one of its threads) experiences an "exception", and i don't "handle" the exception, Windows will eventually handle it by killing the application. If an unhandled exception happens while in kernel mode, the OS has no choice but to handle it by shutting down the kernel. What i was interested in is which exception was being thrown. i assumed (incorrectly, it turns out) it was an "Access Violation".

i know that all bugchecks are accompanied by four parameters that describe what actually happened:

  • Parameter 1: 0xFFFFFFFFC0000096
  • Parameter 2: 0xFFFFF80003610698
  • Parameter 3: 0xFFFFF8800614C7B8
  • Parameter 4: 0xFFFFF8800614C010

But what the hell do these mean?! That's when we turn back to the documentation page, which doesn't describe them. But it does say:

Bug check 0x1000007E has the same meaning and parameters as bug check 0x7E (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED).

Excellent. And this other page documents the parameters:


The following parameters appear on the blue screen.

  • Parameter 1: The exception code that was not handled
  • Parameter 2: The address where the exception occurred
  • Parameter 3: The address of the exception record
  • Parameter 4: The address of the context record

This is what i wanted, the exception code that was not handled. In your case it was exception code:


i know, from experience, that you're running on a 64-bit Windows, because that code is 64-bits long. Really i only want the lower 32-bits:


Normally i would have expected to find that error code in winerror.h in my development directory; but it wasn't there. It took some Binging, but i found that searching for:

winerror C0000096

lead me to a page on winehq, that declared the constant:


Binging for that constant lead me a canonical Microsoft documentation page:

Hardware Exceptions

STATUS_PRIVILEGED_INSTRUCTION:Executing an instruction not allowed in current machine mode.

I also know that this exception is thrown by the CPU itself. i know that because "Privileged Instruction" means you tried to execute a CPU instruction you're not allowed. i also can know this because the page is called Hardware Exceptions.

So we're at the point were some code was running that tried to execute a CPU instruction it wasn't supposed to. There's two possibilities:

  • memory was corrupted; the software wasn't written to try to execute that code, but that's what just ended up in RAM
  • it really is buggy software, and it tried to do something it's not allowed.

Given that Microsoft's code is constantly being field tested in millions of machine's every day, it's more likely:

  • to be a problem with your hardware
  • a bug in someone else's code causing problems

Anyway, that was how i worked on that bugcheck. Maybe by knowing how i went through it, it can help you the next time you have a bugcheck.

share|improve this answer
Thank you! Would you recommend a specific tool that allows me to check/update my drivers to their latest version, or should I do it manually? –  cr0z3r Feb 12 '13 at 14:45
@cr0z3r I have never found a single generic driver checker (I am talking about ones that check all drivers on your computer, not ones that check to see if a specific driver is up to date) that was not a scam/full of adware. I would go to each manufacture's website your self. –  Scott Chamberlain Feb 12 '13 at 15:13
@ScottChamberlain Precisely my point.. they always offer a trial version that lists a billion outdated drivers, but only after purchasing their pro-super-exclusive version are you (supposed to be) able to update them automatically. Anyhow, manual work it is. Thank you! –  cr0z3r Feb 12 '13 at 15:20
It's not safe to assume that. Microsoft only has drivers that manufacturers submit to WHQL for WHQL testing. In my case, that meant a network chipset driver that was ten years old, rather than the one created last year. Realtek never bothered to submit it to Microsoft; so Windows Update won't have it. That's why you'll have to go to the manufacturers - sometimes. My motherboard's USB3.0 chipset has no drivers on Windows Update; i had to go to their web-site. nVidia doesn't always update WHQL drivers. Sometimes even motherboard chipset drivers. –  Ian Boyd Feb 13 '13 at 15:38
On the other hand, you don't want to be updating drivers willy-nilly. Sometimes the latest and greatest has bugs that haven't been found yet. i prefer to trust WHQL certified drivers (off Windows Update). But if you're having a problem with something, you have no choice but to update the drivers. –  Ian Boyd Feb 13 '13 at 15:39
show 4 more comments

Your Answer


