MEMORY_MANAGEMENT bsod with subtype 0x61941 when iterating through PTEs

Hello!

I am a hobbyist and I am trying to develop a program that iterates through PTEs of physical memory to scan for patterns.

I tested this driver in a VM and it worked perfectly fine, no hanging.

When I test on my host computer, I have problems.
My computer hangs around 15 seconds after the scan starts and windbg does not capture any crash dump or crash info (it’s as if windbg doesnt know about the BSOD)

Yes, I am doing invlpg after each page access

@Adam_Smith … First, I have edited your original username. It’s not funny. It’s the name of a real person, who I know personally, and who used to work at OSR. You are not that person. I have no clue why you would choose that name. But it pisses me off.

So I chose a different name for you, that of a Scottish economist.

As for your question… I‘ll leave it to someone else to answer.

Peter

Are you just looking, or are you changing things? In a real environment, the page tables are incredibly dynamic, changing often and quickly. If you are, for example, changing an entry and restoring it later, I have no doubt that would cause crashes.

> @Tim_Roberts said: > Are you just looking, or are you changing things? In a real environment, the page tables are incredibly dynamic, changing often and quickly. If you are, for example, changing an entry and restoring it later, I have no doubt that would cause crashes. I am iterating through physical pages by allocating a page and changing the PFN around. Would you suggest any alternative?

You ARE taking into account the fact that devices are mapped into the physical address space, right? And that part of the “device address space hole” might not have ANYTHING behind it??

Peter

@“Peter_Viscarola_(OSR)” said:
You ARE taking into account the fact that devices are mapped into the physical address space, right? And that part of the “device address space hole” might not have ANYTHING behind it??

Peter

I am reading directory base in kernel mode using _readcr3()

and I am only scanning pages that are present and writable

Hmmmm… I’m a bit confused by the model you’re using… by what you’re trying to do. So… let’s start at the beginning:

Your driver is running in some context (specific or arbitrary, you haven’t said). You’re going to examine all the physical pages that are within (some subset of?) the virtual address space of that context. You haven’t said whether you’re looking at the high or low half or both of the kernel virtual address space.

A few questions:

a) You DO understand that what you’re doing is very far outside the bounds of what you’re allowed to do by Windows OS architecture, right?

b) The virtual to physical mapping can be constantly changing… so what was valid 1 millisecond ago (when you looked at the PTE contents) may not be valid now. Right?

c) Since these pages are already IN your Virtual Address space, why would you need to remap them into a different virtual address space?

d) If you’re looking at the upper-half of kernel virtual address space there absolutely will be device memory mapped there. And just READING device memory that you don’t own can do… unpredictable… things.

Why in the name of heaven are you doing ANY of this? On its face, given what little you’ve told us, it does not seem to be a very sensible project.

Peter

@“Peter_Viscarola_(OSR)” said:
Hmmmm… I’m a bit confused by the model you’re using… by what you’re trying to do. So… let’s start at the beginning:

Your driver is running in some context (specific or arbitrary, you haven’t said). You’re going to examine all the physical pages that are within (some subset of?) the virtual address space of that context. You haven’t said whether you’re looking at the high or low half or both of the kernel virtual address space.

A few questions:

a) You DO understand that what you’re doing is very far outside the bounds of what you’re allowed to do by Windows OS architecture, right?

b) The virtual to physical mapping can be constantly changing… so what was valid 1 millisecond ago (when you looked at the PTE contents) may not be valid now. Right?

c) Since these pages are already IN your Virtual Address space, why would you need to remap them into a different virtual address space?

d) If you’re looking at the upper-half of kernel virtual address space there absolutely will be device memory mapped there. And just READING device memory that you don’t own can do… unpredictable… things.

Why in the name of heaven are you doing ANY of this? On its face, given what little you’ve told us, it does not seem to be a very sensible project.

Peter

What kind of alternative would you suggest? I want to scan through the entire kernel virtual address space.

“I want to scan through the entire kernel virtual address space” doesn’t really mean anything sufficiently specific. WHAT in “the kernel virtual address space”? The graphics RAM is in the kernel virtual address space… do you want to scan that?

If you want somebody to spend their valuable time thinking about your problem and typing an answer that might help you, the LEAST you owe us is to take the time to clearly and comprehensively describe what you are trying to accomplish.

Peter

I want to scan through the entire kernel virtual address space.

You can’t do that. There are hardware devices memory mapped into the kernel virtual address space. Some of those devices will have potentially damaging side effects when you read their memory space.

@“Peter_Viscarola_(OSR)” said:
“I want to scan through the entire kernel virtual address space” doesn’t really mean anything sufficiently specific. WHAT in “the kernel virtual address space”? The graphics RAM is in the kernel virtual address space… do you want to scan that?

If you want somebody to spend their valuable time thinking about your problem and typing an answer that might help you, the LEAST you owe us is to take the time to clearly and comprehensively describe what you are trying to accomplish.

Peter

@Tim_Roberts said:

I want to scan through the entire kernel virtual address space.

You can’t do that. There are hardware devices memory mapped into the kernel virtual address space. Some of those devices will have potentially damaging side effects when you read their memory space.

How would I avoid touching these memory mapped devices?

What part of “clearly and comprehensively describe what you are trying to accomplish” did you not understand?

Peter

P.S. Just so I’m being cross-culturally and super abundantly clear: I’m an inch away from banning you from the forum and deleting this thread. You started badly, didn’t apologize for your poor choice of username after I “corrected” it for you, and have now – twice – refused to answer the reasonable questions I’ve asked. That is not a good start, for somebody who is seeking assistance from my friends in my house. Just sayin…

How would I avoid touching these memory mapped devices?

By not doing what you are doing. We’ve tried to say it in detail, and we’ve tried to say it succinctly. I will repeat: YOU CAN’T DO THAT. Your project is hopeless. Abandon it, and find something that CAN be done.