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

Home NTFSD

Before Posting...

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

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/


FltSendMessage - ClientPort use

Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 636
Hi,

Does anyone know why ClientPort parameter is a pointer to a pointer and not directly a single pointer?
If the variable (let's call it g_ClientPort) is not modified inside FlrSendMessage why does it need a pointer to it? It's defined as _in, and I don't see in the disassembly that it is modified directly, but maybe a subcall does it.

Strangely, I never saw code that copied the variable and passed a pointer to different variables yet :)

OT: what was the email to use to post without going to the forum?

Dejan.

Comments

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,679

    @Dejan_Maksimovic said:
    Hi,

    Does anyone know why ClientPort parameter is a pointer to a pointer and not directly a single pointer?
    If the variable (let's call it g_ClientPort) is not modified inside FlrSendMessage why does it need a pointer to it? It's defined as _in, and I don't see in the disassembly that it is modified directly, but maybe a subcall does it.

    It's a cute way to clean up the race between FltSendMessage and FltCloseClientPort without external synchronization:

    • FltSendMessage grabs your filter lock shared and checks to see if *ClientPort is NULL.
    • FltCloseClientPort grabs your filter lock ex and sets *ClientPort to NULL

    OT: what was the email to use to post without going to the forum?

    We'd really prefer everyone just use the forum at this point...We did a bunch of work to "grandfather in" email access to some people when we moved the site 5+ years ago but it's mostly just a pain (and I'm still not over having to give up NNTP access 😂).

    -scott
    OSR

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 636
    via Email
    > > Does anyone know why ClientPort parameter is a pointer to a pointer
    > and not directly a single pointer?
    > >
    > > If the variable (let's call it g_ClientPort) is not modified inside
    > FlrSendMessage why does it need a pointer to it? It's defined as _in, and I
    > don't see in the disassembly that it is modified directly, but maybe a
    > subcall does it.
    >
    > It's a cute way to clean up the race between FltSendMessage and
    > FltCloseClientPort without external synchronization:
    >
    So, it does need for the same variable's address to be passed, and not the
    value to be copied around? Thanks!

    >
    > *



    > We'd really prefer everyone just use the forum at this point...We did a
    > bunch of work to "grandfather in" email access to some people when we moved
    > the site 5+ years ago but it's mostly just a pain (and I'm still not over
    > having to give up NNTP access 😂).
    >

    I don-t think you know how much easier e-mail is :D

    Regards, Dejan.
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,679

    @Dejan_Maksimovic said:
    So, it does need for the same variable's address to be passed, and not the
    value to be copied around? Thanks!

    Correct.

    I don-t think you know how much easier e-mail is :D

    For you maybe but not for the forum or its indentured servants 😁 (I, for one, definitely don't miss seeing broken threads everywhere starting with "RE: re: Re: AW: aw: RE: SV: RE: [NTFSD]")

    -scott
    OSR

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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!
Kernel Debugging 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online