Can we catch any exception thrown from accessing invalid/paged-out addresses of usermode?

As far as i know, and have experienced, when i access user mode addresses for reading, i combine PorbeForRead + a try catch block to make the code 100% safe and no risk of getting BSOD.

but i was wondering, if i combine porbeforread + try catch, will this be able to catch any exception thrown from accessing a invalid or paged out address in user-mode from my driver? even if IRQL is higher or equal to DISPATCH_LEVEL?

Nope. You can’t call ProbeForRead at IRQL >= DISPATCH_LEVEL. From the docs:

Peter

@“Peter_Viscarola_(OSR)” said:
Nope. You can’t call ProbeForRead at IRQL >= DISPATCH_LEVEL. From the docs:

Peter

So there’s no safe way of accessing the user-mode addresses inside a callback that can be called at IRQL >= DISPATCH_LEVEL?

Nope. You will need to spin off a work item. User mode memory is toxic.

@Tim_Roberts said:
Nope. You will need to spin off a work item. User mode memory is toxic.

But if the callback is always called at IRQL < DISPATCH_LEVEL, then its safe to read any address in user mode as long as i combine try catch with ProbeForRead?

then its safe to read any address in user mode as long as I combine try catch with ProbeForRead?

It depends, for example if you write a minifilter driver during the “paging I/O” path you are not allowed to access memory that can be paged out because it will BSOD. Also it depends what you do with this user mode memory, if you parse user mode memory incorrectly it may lead to a BSOD

then its safe to read any address in user mode as long as i combine try catch with ProbeForRead

Yes. And remember that ProbeForRead checks that the address is a user mode address. So that’s not a separate step.

Peter

then its safe to read any address in user mode as long as i combine try catch with ProbeForRead?

Maybe it’s not necessary to add, but “any address in user mode IN THE CURRENT PROCESS”. For top-level drivers, that’s not too much of a problem, but for deeper drivers you need to be aware of what the current process is.

@Tim_Roberts said:
but for deeper drivers you need to be aware of what the current process is.

Can you elaborate on this please? what do you mean by deeper drivers? and what more should i do other than try catch + probeforread?

what do you mean by deeper drivers?

I mean drivers that are deeper in the driver stack – drivers that communicate with other drivers and aren’t immediately user-facing. The deeper you go, the looser the connection to user mode, and the more likely that some driver above you has triggered a context switch.

Can you elaborate on this please

Well, as Mr. Roberts correctly noted, accessing ANY user-mode address assumes you know which process context in which you’re running.

If you’re the first driver entered from the I/O Manager (and not a WDF driver), you know you’re being called in the context of the requesting process/thread. You’re being called in a specific, known, thread context. If you’re NOT the first driver entered from the I/O Manager – for example, you’re a driver that receives requests from other drivers, such as the Volume Manager – then you’re called in an arbitrary process and thread context (and so, by definition, you don’t know what user process is currently active, or even if there IS one).

If you have a user-mode address, that address is only useful if you know the specific process context to which the address applies, right?

Peter