Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

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

brad_Hbrad_H Member Posts: 18

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?

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,448

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

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • brad_Hbrad_H Member Posts: 18

    @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?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,939

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

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • brad_Hbrad_H Member Posts: 18

    @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?

  • 0xrepnz0xrepnz Member Posts: 57

    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

    - Ori Damari
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,448

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,939

    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, [email protected]
    Providenza & Boekelheide, Inc.

  • brad_Hbrad_H Member Posts: 18
    edited May 3

    @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?

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,939

    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.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,448

    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

    Peter Viscarola
    OSR
    @OSRDrivers

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 27 September 2021 Live, Online
Kernel Debugging TBD 2021 Live, Online