BAD_POOL_HEADER [COLOR=red](19)[/COLOR]
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 0000000000000020, a pool block header size is corrupt.
Arg2: fffffa80058ac100, The pool entry we were looking for within the page.
Arg3: fffffa80058ac120, The next pool entry.
Arg4: 0000000004020010, (reserved)
Debugging Details:
----------------------------------!thread
Use !analyze -v to get detailed debugging information.
BugCheck[COLOR=red] 50[/COLOR], {fffff8e0009ea9bc, 1, fffff80001dae2c2, 5}
Could not read faulting driver name
Probably caused by : ntkrnlmp.exe ( nt!ExFreePoolWithTag+212 )
Followup: MachineOwner
---------------------
IRQL_NOT_LESS_OR_EQUAL [COLOR=red](a)[/COLOR]
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000001928, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff80002aebd79, address which referenced memory
Debugging Details:
--------------------------------------
Use !analyze -v to get detailed debugging information.
BugCheck [COLOR=red]1000007E[/COLOR], {ffffffffc0000005, fffff880047cacf7, fffff88005c9a6a8, fffff88005c99f00}
Probably caused by : Unknown_Module_fffffa80`04f55cb8 ( Unknown_Module_fffffa80`04f55cb8>+289c348 )
Followup: MachineOwner
------------------------------------------
PAGE_FAULT_IN_NONPAGED_AREA [COLOR=red](50)[/COLOR]
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: fffff8800c705ff8, memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: fffff88001292a90, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000000, (reserved)
----------------------------------------------
KMODE_EXCEPTION_NOT_HANDLED [COLOR=red](1e)[/COLOR]
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: 0000000000000000, The exception code that was not handled
Arg2: 0000000000000000, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: 0000000000000000, Parameter 1 of the exception
