


Now that we know all of this, let's go ahead and run !pte on the 1st parameter address. This doesn't tell us anything weĭon't already know about the bug check, just a confirmation, if you We can see above that the 1st parameter address was stored in cr2 prior So, we can so far say that address fffffa806589b700 was written to by the instruction at address fffff803fd7133d4. Non-zero), is the instruction address which referenced the bad memoryĪddress (parameter 1).

See, parameter 1 is the memory that was referenced, and parameter 3 (if Here we of course have the basic output of the bug check. Typically the address is just plain bad or itĪrg1: fffffa806589b700, memory referenced.Īrg2: 0000000000000000, value 0 = read operation, 1 = write operation.Īrg3: fffff803fd7133d4, If non-zero, the instruction address which referenced the bad memory However, what if we're not so quick toīlame the antivirus, and come to find instead that it's faulty RAM? Protections are running (maybe two antiviruses running at once), etc. Interceptors conflicting if anti-malware and antivirus active 0x50, the bug check we all love because it's so easy to say 'Remove avast!, AVG, Kaspersky, McAfee, Norton, ESET, etc' because most commonly thisīug check is caused by antiviruses corrupting the file system,
