How the BSOD actually 'works', why, etc.

Patrick

Sysnative Staff
Joined
Jun 7, 2012
Posts
4,618
So on Sysnative we've talked many times in-depth regarding postmortem debugging kernel-dumps as far as blue screen crashes goes. Well, I decided maybe it's time to go ahead and actually in detail explain why a blue screen occurs, what actually goes on when a blue screen occurs, etc.

-- Disclaimer: At the time of this post, I have never myself experienced a BSOD on my Windows 8.1 system, so I cannot 100% confirm whether or not the display is shifted to a low-res VGA mode when paining the screen. I may use NotMyFault to test this out and will edit when I get a confirmation. For now though, let's assume nothing has changed and hope I'm correct : )



First off, why does the blue screen of death occur? Well, it's important to know that there are many reasons as to why a blue screen occurs. Just to name a few:


  • References to invalid/inaccessible memory; causes access violations, etc.
  • Unexpected exceptions.
  • Bugs in drivers causing a fault in a kernel-mode driver, 3rd party drivers doing what I first mentioned, etc.

Again, this is very few of the potential reasons why, but some of the most prevalent. For those interested, here's actually a distribution of what causes bug checks most commonly in Windows.

6758.Error_categories_distribution.jpg

Above is a picture I found on Google from a TechNet article, so thanks to the author for this! It's from Windows Internals - 5th Edition. AFAIK there is not one in the 6th, at least I have not seen it throughout my reading or research afterwards. With this said, it's likely not entirely accurate in regards to today, but I imagine it has not changed too much. Given I analyze postmortem kernel-dumps quite a bit, I am surprised to see pool is so low. Again, this was way back in the writing of the 5th edition which was during Vista's legacy, so many things have changed since then. It's up in the air, really!

Now, with that said we understand a few reasons as to why Windows stops and a blue screen occurs. Good! Now let's also go ahead and understand that if any of these things occurred, Windows could theoretically not stop and keep going when one of these is occurring. Why doesn't it just do this? Well, it's actually extremely simple, and that's because many of these things can cause severe data/memory corruption which could actually lead to hardware problems.

Since we don't want any of that, Windows thankfully has a fail-safe known to us as the Blue Screen of Death (BSOD -- abbreviating from now on). If Windows detects that there is a serious problem that is unrecoverable, it will stop all executions, switch the display to the basic/low-res VGA mode, paint the actual blue screen itself, write memory/crash information to what we know as a memory dump (crash dump/dmp file/dmp), and display a stop code (bug check). All of this is done through a series of functions.

Now that we're on this topic, I must STRESS and dispel the misconception right now that the blue screen itself is a bad thing. It's not! The blue screen is a good thing, and it's making it so our data doesn't become completely corrupt. Remember, the blue screen happens because Windows has detected something has gone horribly wrong, and it cannot recover and/or stop it. When this happens, the appropriate bug check based on what caused the error is called, and the blue screen is painted.

Bottom line... the blue screen is our friend, not our enemy : )



As discussed above, a blue screen happens when Windows detects that there's an unrecoverable/irreversible problem occurring. Regardless of what this actual problem is, the end result is a blue screen. As I mentioned above, this blue screen process actually happens through functions.

Despite the belief that there is only one function that calls and/or begins the bug check process, it is not true! There's two!



(Clickable for their MSDN links)!


First off, before stating their differences, let's make it easy by saying that both of these functions take what is known as a BugCheckCode parameter. What is a BugCheckCode parameter? Good question! This parameter is otherwise known as a STOP code (for example - 0x0000000A, 0x0000001A, 0x0000009F, etc). These stop codes (otherwise known as/called 'bug checks') are what allows us (other than actually debugging the crash dump itself) to troubleshoot the blue screen. It allows us to go ahead and troubleshoot because each of these STOP codes has an actual preset meaning/cause as to why it occurred.

Great, so now that we know that information, what is the difference between KeBugCheckEx and KeBugCheck? Good question! KeBugCheck calls KeBugCheckEx and sets the four parameters to zero.

Example - {0,0,0,0}

Essentially, the KeBugCheckEx function itself provides more information because it sets the four parameters to their preset meanings based on the STOP code/bug check.



Once KeBugCheckEx is called, it first goes ahead and disables all interrupts by calling the KiDisableInterrupts function. After this is done, it transitions to a special system-state in which the STOP code is dumped (0x0000000A for example). It accomplishes the transition and dump of the STOP code with a call from KiDisableInterrupts to the HalDisplayString function.

HalDisplayString itself goes ahead and first takes one parameter (string to print to the blue screen), and does a check to see if the system is in its special system-state (blue screen 'mode'). If it is not in this state however, it will go ahead and attempt to successfully use the firmware to swap to this proper system-state in order to continue.

Once the check has been successfully completed and confirmed that the system is in its proper state, HalDisplayString goes ahead and dumps the string into text-mode video memory at the current location of the cursor. This is kept track of throughout all of the future calls.

After all of this is successfully accomplished, KeBugCheckEx then goes ahead and calls the KeGetBugMessageText function. The KeGetBugMessageText translates the stop code into its text-equivalent. There's a bug check reference list here.

Once that is completed, KeBugCheckEx will then go ahead at this point and start to call any bug check handlers that drivers registered (if any). The handlers themselves are registered by calling KeRegisterBugCheckCallback which goes ahead and fills in a buffer that is allocated by the caller of the register routine so it can be debugged in the debugging client. It also essentially in general allows any drivers a chance to stop their devices.

Once that is through, we move on to calling the KeRegisterBugCheckReasonCallback function which goes ahead and allows any drivers to write data to the crash dump or write crash dump information to alternate devices.

Once the above is done (if possible, because handlers aren't always registered) KeDumpMachineState is called which dumps the rest of the text on the screen. However, the first thing KeDumpMachineState tries to do is successfully interpret the four parameters that were passed to KeBugCheckEx as a valid address within a loaded module. It will go ahead and stop when it can successfully resolve one. The function that is used to accomplish this is KiPcToFileHeader.

KiPcToFileHeader returns for the first parameter that it goes ahead and successfully resolves, immediately prints the following text form of the STOP code, and also includes the base address of the module and the module’s name.



Below I will share the difference between your standard 8/8.1 and XP/Vista/7 screens:

blue_screen_of_death 8.png

(Windows 8/8.1 displaying 0x5C bug check)

blue_screen_of_death xp_vista_7.jpg

(Windows XP/Vista/7 displaying 0x50 bug check)



Thanks for reading, and thanks to NT Insider and MSDN as always for double-checking!


 
Last edited:
Thanks Patrick. Keep up your good work ^_^

Even though I do the analysis which is very low as compared to you :P, I see a greater share of WHEA_Uncorrectable_Error ; Driver_Power_State_Failure (With first parameter 3) & Kernel_Data_Inpage Error.

These are the 3 current top bugchecks in my list.

I remember when I was a kid, dad bought in this Windows 98 PC and it used to go BSOD sometimes after shifting to Windows XP and I was like praying to the gods that gods please don't screw up this PC and I was like what if dad learnt what happened to the pc :P


But, now, yeah BSOD's are pretty friendly ^_^
 
Just had a doubt in my mind, why is KeBugCheck called in the first place when it has to call only a single function i.e. KeBugCheckEX? The KeBugcheckEX only sets the four parameters to zero but that should be achievable using the KeBugCheckEX as well?
 
KeBugCheck is not called by default, KeBugCheckEx is. KeBugCheck still exists though, it can be called if you choose to call it (although I am unsure as to why you would).
 
I do as well.

IMO it's better in practically every way as it gives you as basic 'why' it occurred, to contact your system admin/manufacturer, etc. The W8 one just says 'search it online'.

I guess MS wanted to make the BSOD a lot less 'scarier' for the average home user.
 
I'm still scared of it ;)

But yes I prefer the Windows 7 one, I mean it would still be annoying if the Windows 8 one occurred, I don't see the reason really.

It's more practical as sometimes dump files aren't created etc and a screenshot can help where as the Windows 8 one doesn't help much.
 
I just noticed this topic! Sweet! Fascinating info on how the calls are made!

One question that I haven't been able to find the answer to: Where are the descriptions of the arguments/parameters found (prior to the crash)?

A picture w/percentages of types of BSOD's in Win7/7 SP1 is in Windows Internals, 6th Edition, Part 2, page 551
AFAIK - the numbers come from the automated reporting of BSOD's through WER
Users don't always pay attention to this - and, sometimes, they refuse to let Microsoft collect info on this. So the numbers are skewed by the users.
Also, people looking for help with BSOD's are generally a bit more technically able than others (even if they say they don't know anything about computers).
Those who really don't know anything will just take their systems to a shop to have a BSOD fixed (and many techs will wipe a system to fix a BSOD).

At one point I started researching how dump files were generated. The results are here: BSOD Crash Dump Generation
Last updated: 02 May 2011

As for the Win8 BSOD - it's not that bad. You just have to search the Symbolic Name rather than the STOP error code.
The only problem that I've ever had with this was when I wanted to look at the arguments/parameters.
But there's just not that many people that want to look at the parameters, and most of them likely know how to run a memory dump through the debugger in order to find it (and they'll get more use out of the debugger output than just the parameters)

5 PHASES OF DUMP FILE GENERATION (Setup, user adjustment of settings, during the boot, during the crash, after the reboot):

Phase 1 (Setup)
The system obtains much of the initially required settings/entries automatically while Windows is installing - so you won't even know that this is going on. It's determined by the hardware on your system and how Windows interprets this information during setup. Unless you're an advanced user, there's very little opportunity for you to influence the factors involved in this phase.

Phase 2 (User adjustments)
Next is the opportunity for the user to modify settings. This not only includes the BSOD settings in Control Panel and in the registry, but also includes unrelated settings that amy affect the generation/collection of memory dumps. One such example is the settings used for the pagefile. There's a list of the registry settings at BSOD-related Registry Entries

Phase 3 (During the boot - the one preceding the crash)
Hal.dll and boot start drivers load before the pagefile is initialized - so a BSOD then can't save a memory dump (hence, live debugging is required to capture a memory dump)
Creation of pagefile occurs during the Memory Manager initialization (part of the kernel initialization - I believe it's in Phase 1)
At boot, the system checks the crash dump options in the Registry (HKLM\SYSTEM\CurrentControlSet\Control\CrashControl)
If a dump is configured, it makes a copy of the disk miniport driver and appends "dump_" at the beginning of the filename
System then checksums (and saves) the components involved in generating the memory dump. (dump_ miniport driver, I/O Manager functions that write the dump, and the map of where the boot volume's paging file is on disk).

Phase 4 (The crash itself)
When the KeBugCheck function executes, it checksums the components again.
If they don't match, then no dump is written (to prevent data corruption)
If they do match, then the dump is written directly to the sectors occupied by the pagefile. It bypasses the file system and storage driver stack (including the disk miniport driver) - using the dump_ copied driver instead.
If a dedicated dump file is specified, then the crash dump driver (crashdump.sys) creates the dump file and it's required size and writes it to the dedicated dump file location (instead of the pagefile). If not enough space for a complete or kernel dump - the system falls back to writing a minidump.

Phase 5 (After the reboot)
For more detail, see Boot Process Troubleshooting page here: Boot Troubleshoot
During the reboot, the Session Manager (SMSS.exe) enables paging (function NtCreatePagingFile)
and the system then checks to see if there's a dump file (by calling function SmpCheckForCrashDump)
If there is a dump file, that portion of the pagefile is protected (may result in low virtual memory error messages)
During this time (Phase 0 of kernel initialization - generally before Windows Splash Screen shows up), Driver Verifier is enabled and then Kernel Debugger is attached (if used). Initialization is finished later on (see Boot Troubleshoot )
If the target dump file is located on another drive, then the system (winlogon.exe calling savedump.exe) renames the pagefile to Dumpxxx.tmp (from pg 1130 of Windows Internals 5th Edition) and truncates the size to the size of the dump data (stored in the header of the dump file). Removes Hidden and System attributes from the file
Creates volatile Registry key: HKLM\SYSTEM\CurrentControlSet\Control\CrashControl\MachineCrash
Stores temporary dump file name in the value "DumpFile". Writes REG_DWORD to "TempDestination" value indicating if it's a temporary destination or not (0x0 = not temp; 0x1 = temp)
NOTE: If the pagefile is on the same volume as the final memory dump location - then no temporary file is used and TempDestination value is set to 0x0
Later on wininit.exe checks for the MachineCrash key. If found, Wininit.exe launches WerFault.exe -k -c (k=kernel report; c=convert to minidump) which either renames or copies the temporary file to the final location
WerFault then writes the final dump name to the MachineCrash\FinalDumpFileLocation value



Ya gotta wonder when and how the MachineCrash key is deleted

The Microsoft Bug Check Reference (located here: Bug Check Code Reference (Windows Debuggers) ) is incomplete.
Scrolling down the list will show many missing bug checks
A more comprehensive listing is in the bugcodes.h file (I think it's from the WDK - I haven't researched it since 8.1 came out). I maintain a copy of it here: bugcodes.h v8.1
Finally, there's even more BSOD error codes than this. At last count I'd documented over 406 BSOD error codes here: BSOD Index
 
Last edited:
I had a question in mind that does every time a Blue Screen occurs, the KeBugCheck() function is called. But, is it necessary that it must be present in the stack as well? Asking because just encountered a dump file where there is only 2 lines both stating the Intel Rapid Storage Driver as the only call. The KeBugCheck() is nowhere to be seen. So, could anyone please explain this?

Also, how come that after every one week or so, the people having BSOD problems are generally having the same set of software and driver versions like acronis(Just example)? Furthermore, I remember that before Patrick created the Wiki article for the Intel Rapid Storage driver problem, there were loads of those cases but now there are hardly any?


@Usasma :- there is a typo in the Phase 2 "amy" must be "may" .
 
Can you PM me the dump? I'll take a look post the findings here.

Furthermore, I remember that before Patrick created the Wiki article for the Intel Rapid Storage driver problem, there were loads of those cases but now there are hardly any?

I haven't seen it in a few weeks either. Either OEM's are finally cleaning up their act and releasing fixed versions of the driver, or people just haven't been installing it. Time will tell.
 
Can you PM me the dump? I'll take a look post the findings here.

Furthermore, I remember that before Patrick created the Wiki article for the Intel Rapid Storage driver problem, there were loads of those cases but now there are hardly any?

I haven't seen it in a few weeks either. Either OEM's are finally cleaning up their act and releasing fixed versions of the driver, or people just haven't been installing it. Time will tell.

Dumps PMed. Furthermore, can anyone shed light on this one that whether calling KeBugCheck() is possible by creating a simple Win 32 Application?
 
Furthermore, can anyone shed light on this one that whether calling KeBugCheck() is possible by creating a simple Win 32 Application?

It is not possible. There are two ways of attempting to load a a binary (and subsequently call a function) from usermode code (load time dynamic linking or run time dynamic linking), but neither will work.

If you try to use LoadLibrary & GetProcAddress on ntoskrnl.exe & KeBugCheck respectively, you'll just get errors. If you try to include ntddk.h import library into a Win32 C++ app, it won't compile. There will be for starters a conflict between the Win32 CRT and the WinDDK CRT headers. So you perhaps take out the Win32 CRT headers to avoid that conflict. It still won't compile though. So you make some further tweaks here and there, and eventually you get it to compile. Great! But you know what? - you'll now have actually coded a driver. All those changes you made in order to get it to compile will have changed your project into a driver project. Oh yes, you started out with a Win32 project, but that's not what you've got now.

So to answer your question, no, it cannot be called from Usermade. The closest you can get is to write a kernel mode device driver which exposes a usermode version of KeBugCheck and call that from usermode. Precisely what the SysInternals tool does (the name's slipped my mind! That one which causes BSODs...)
 
Thank you very much Richard for explaining it this clearly and deeply ^_^.
 
Can you PM me the dump? I'll take a look post the findings here.

Furthermore, I remember that before Patrick created the Wiki article for the Intel Rapid Storage driver problem, there were loads of those cases but now there are hardly any?

I haven't seen it in a few weeks either. Either OEM's are finally cleaning up their act and releasing fixed versions of the driver, or people just haven't been installing it. Time will tell.

Dumps PMed. Furthermore, can anyone shed light on this one that whether calling KeBugCheck() is possible by creating a simple Win 32 Application?

NtRaiseHardError is the user mode BSOD function.

The function shows a blue screen if the ResponseOption parameter is OptionShutdownSystem (6). The application must first enable SeShutdownPrivilege.
 
Furthermore, if one is interested, I found this in the WinDBG manual :-


[h=1]Forcing a System Crash from the Keyboard[/h]
Most of the following keyboards can cause a system crash directly:
PS/2 keyboards connected on i8042prt ports This feature is available in Windows 2000 and later versions of Windows operating system.
USB keyboards This feature is available in:

  • Windows Server 2003 Service Pack 1 if the hotfix available with KB 244139 is installed.

  • Windows Server 2003 (with Service Pack 2 or later).
  • Windows Vista Service Pack 1 if the hotfix available with KB 971284 is installed.
  • Windows Vista Service Pack 2.
  • Windows Server 2008 Service Pack 1 if the hotfix available with KB 971284 is installed.
  • Windows Server 2008 (with Service Pack 2 or later).
  • Windows 7 and later versions of Windows operating system.
Note This feature is not available in Windows XP.
You must ensure the following three settings before the keyboard can cause a system crash:

  1. If you wish a crash dump file to be written, you must enable such dump files, choose the path and file name, and select the size of the dump file. For more information, see Enabling a Kernel-Mode Dump File.
  2. With PS/2 keyboards, you must enable the keyboard-initiated crash in the registry. In the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\i8042prt\Parameters, create a value named CrashOnCtrlScroll, and set it equal to a REG_DWORD value of 0x01.
  3. With USB keyboards, you must enable the keyboard-initiated crash in the registry. In the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\kbdhid\Parameters, create a value named CrashOnCtrlScroll, and set it equal to a REG_DWORD value of 0x01.
You must restart the system for these settings to take effect.
After this is completed, the keyboard crash can be initiated by using the following hotkey sequence: Hold down the rightmost CTRL key, and press the SCROLL LOCK key twice.
The system then calls KeBugCheck and issues bug check 0xE2 (MANUALLY_INITIATED_CRASH). Unless crash dumps have been disabled, a crash dump file is written at this point.
If a kernel debugger is attached to the crashed machine, the machine will break into the kernel debugger after the crash dump file has been written.
For more information on using this feature, refer to the article Generate a memory dump file by using the keyboard (KB 244139).
[h=4]Defining Alternate Keyboard Shortcuts to Force a System Crash from the Keyboard[/h] You can configure values under the following registry subkeys for different keyboard shortcut sequences to generate the memory dump file:

  • For PS/2 keyboards:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\crashdump
  • For USB keyboards:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\crashdump
You must create the following registry REG_DWORD values under these subkeys:
Dump1Keys The Dump1Keys registry value is a bit map of the first hot key to use. For example, instead of using the rightmost CTRL key to initiate the hot key sequence, you can set the first hot key to be the leftmost SHIFT key.
The values for the first hot key are described in the following table.
ValueFirst key used in the keyboard shortcut sequence
0x01
Rightmost SHIFT key
0x02
Rightmost CTRL key
0x04
Rightmost ALT key
0x10
Leftmost SHIFT key
0x20
Leftmost CTRL key
0x40
Leftmost ALT key

Note You can assign Dump1Keys a value that enables one or more keys as the first key used in the keyboard shortcut sequence. For example, assign Dump1Keys a value of 0x11 to define both the rightmost and leftmost SHIFT keys as the first key in the keyboard shortcut sequence.
Dump2Key The Dump2Key registry value is the index into the scancode table for the keyboard layout of the target computer. The following is the actual table in the driver.
const UCHAR keyToScanTbl[134] = {
0x00,0x29,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,
0x0A,0x0B,0x0C,0x0D,0x7D,0x0E,0x0F,0x10,0x11,0x12,
0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1A,0x1B,0x00,
0x3A,0x1E,0x1F,0x20,0x21,0x22,0x23,0x24,0x25,0x26,
0x27,0x28,0x2B,0x1C,0x2A,0x00,0x2C,0x2D,0x2E,0x2F,
0x30,0x31,0x32,0x33,0x34,0x35,0x73,0x36,0x1D,0x00,
0x38,0x39,0xB8,0x00,0x9D,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0xD2,0xD3,0x00,0x00,0xCB,
0xC7,0xCF,0x00,0xC8,0xD0,0xC9,0xD1,0x00,0x00,0xCD,
0x45,0x47,0x4B,0x4F,0x00,0xB5,0x48,0x4C,0x50,0x52,
0x37,0x49,0x4D,0x51,0x53,0x4A,0x4E,0x00,0x9C,0x00,
0x01,0x00,0x3B,0x3C,0x3D,0x3E,0x3F,0x40,0x41,0x42,
0x43,0x44,0x57,0x58,0x00,0x46,0x00,0x00,0x00,0x00,
0x00,0x7B,0x79,0x70 };

Note Index 124 (sysreq) is a special case because an 84-key keyboard has a different scan code.
If you define alternate keyboard shortcuts to force a system crash from a USB or PS/2 keyboard, you must either set the CrashOnCtrlScroll registry value to 0 or remove it from the registry.
[h=4]Limitations[/h] It is possible for a system to freeze in such a way that the keyboard shortcut sequence will not work. However, this should be a very rare occurrence. Using the keyboard shortcut sequence to initiate a crash will work even in many instances where CTRL+ALT+DELETE does not work.
Forcing a system crash from the keyboard does not work if the computer stops responding at a high interrupt request level (IRQL). This limitation exists because the Kbdhid.sys driver, which allows the memory dump process to run, operates at a lower IRQL than the i8042prt.sys driver.
 
Great read Patrick and responses all around.

I have to admit that on my own computers long before I learned a bit more, I used to just feel like pulling my hair out when a BSOD happened and grind my teeth and spew things I do not generally say (under my breath if others present, or aloud if alone). ;) I did not think of a BSOD as a friend.

It has become more of a friend of late, and more so with reads like Patrick's et al here on Sysnative!

You all are great!
 
Sorry, it took me a bit to get around to the dumps that were PM'd to me. I see the crashes you're talking about:

Code:
6: kd> k
Child-SP          RetAddr           Call Site
ffffd000`edf54918 fffff800`05b508bc iaStorA+0x5e7b7
ffffd000`edf54920 00000000`00000000 iaStorA+0x5e8bc

Only the IRST driver (twice) is in the stack. No error reporting, etc. Note this:

Code:
Mini Kernel Dump File: [COLOR=#ff0000]Only registers and stack trace are available[/COLOR]

So as we know with a minidump you can really only take a look at 'what literally happened at the time of the crash'. My guess is in all of these crashes, we're simply going off the rails once the violation occurs in the driver. I bet if we had a kernel-dump of these exact crashes, we'd likely see the error handling, etc, in the stack.

Code:
0: kd> .exr 0xffffd0002090d6d8
ExceptionAddress: fffff80119b317b7 ([COLOR=#006400]iaStorA+0x000000000005e7b7[/COLOR])
   ExceptionCode: [COLOR=#4b0082]c0000005 (Access violation)[/COLOR]

Why did this violation happen?

Code:
[COLOR=#006400]mov     [/COLOR]r8d,dword [COLOR=#4b0082]ptr[/COLOR] [[COLOR=#0000cd]rax[/COLOR]]

You can see with the instruction we failed on, it was moving a pointer that was stored in the rax register. Okay, let's take a look at rax:

Code:
0: kd> r
[COLOR=#0000cd]rax=0000000000000000[/COLOR] rbx=ffffe001e1400008 rcx=ffffe001e1400008
rdx=00000000002b8b3f rsi=0000000000000000 rdi=00000000002b8b3f
rip=fffff80119b317b7 rsp=ffffd0002090d918 rbp=00000000002b8b3f
 r8=00000000001ae450  r9=0000000000000001 r10=00000000000000ff
r11=0000000000000000 r12=0000000002b8b3f8 r13=ffffe001e1400008
r14=00000000002d3984 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246

We can see rax is null. Great, so we know why the violation occurred, which was because rax was null. What does all of this mean?

Code:
DEFAULT_BUCKET_ID:  [COLOR=#ff0000]NULL_DEREFERENCE[/COLOR]

Ding ding! We dereferened a null pointer (rax) when in this case we wanted to point to a valid memory area. As usual, this is a problem with the IRST driver.



Great read Patrick and responses all around.

Glad you enjoyed it! Indeed, this is one of the many reasons Sysnative is my favorite community. The discussions and teaching never end! I learn something new every day.
 
Last edited:
It's always helpful to have a little programming knowledge in a language like C or C++, some of the errors will make more sense if you know how pointers work and error handling works etc.
 

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

Back
Top