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

Home NTDEV

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/


PsLoadedModuleList

OSR_Community_UserOSR_Community_User Member Posts: 110,217
edited October 23 in NTDEV
Is there a way to programmatically determining the value of
"PsLoadedModuleList"? The value is visible in a crash dump, but I would
like to determine it from within a driver.

TIA,

Craig Denbrook
Sparta, Inc.
Post edited by Peter_Viscarola_(OSR) on

Comments

  • Nick_RyanNick_Ryan Member Posts: 286
    No, it's not exported from ntoskrnl.exe. I believe there are
    undocumented Zw* functions to enumerate loaded modules from KM, if that
    is your intention.

    Denbrook, Craig wrote:

    > Is there a way to programmatically determining the value of
    > "PsLoadedModuleList"? The value is visible in a crash dump, but I would
    > like to determine it from within a driver.
    >
    > TIA,
    >
    > Craig Denbrook
    > Sparta, Inc.
    >
    >

    --
    Nick Ryan
    (Microsoft Windows MVP for DDK)
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Yep, ZwQuerySystemInformation, IIRC. It's documented in the NT Native API
    book.

    -John

    > -----Original Message-----
    > From: Nick Ryan [mailto:[email protected]]
    > Sent: Monday, January 05, 2004 2:17 PM
    > To: Windows System Software Devs Interest List
    > Subject: Re:[ntdev] PsLoadedModuleList
    >
    >
    > No, it's not exported from ntoskrnl.exe. I believe there are
    > undocumented Zw* functions to enumerate loaded modules from
    > KM, if that
    > is your intention.
    >
    > Denbrook, Craig wrote:
    >
    > > Is there a way to programmatically determining the value of
    > > "PsLoadedModuleList"? The value is visible in a crash dump, but I
    > > would like to determine it from within a driver.
    > >
    > > TIA,
    > >
    > > Craig Denbrook
    > > Sparta, Inc.
    > >
    > >
    >
    > --
    > Nick Ryan
    > (Microsoft Windows MVP for DDK)
    >
    > ---
    > Questions? First check the Kernel Driver FAQ at
    http://www.osronline.com/article.cfm?id=256

    You are currently subscribed to ntdev as: [email protected] To
    unsubscribe send a blank email to [email protected]
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    -----Original Message-----
    From: Nick Ryan [mailto:[email protected]]
    > No, it's not exported from ntoskrnl.exe. I believe there are
    undocumented Zw* functions to enumerate loaded modules from KM, if that
    is your intention.
    >

    -----Original Message-----
    From: John Szakmeister [mailto:[email protected]]
    > Yep, ZwQuerySystemInformation, IIRC. It's documented in the NT Native API
    book.
    >

    Both are good responses, but unless I am misunderstanding something, the
    function " ZwQuerySystemInformation" doesn't give the info I am looking for.
    I used the "SystemModuleInformation" structure with this function and was
    able to enumerate all kernel modules in the PsLoadedModuleList. However,
    what I'm trying to find is the actual address of this list. For example, on
    a local Win2K system, the address is "0x8047FD80" and this seems to hold
    between boots. I would like to be able to find this address
    programmatically.

    Any ideas?

    Thanks again,

    Craig Denbrook
    Sparta, Inc.
  • Nick_RyanNick_Ryan Member Posts: 286
    There is no way to find the address programmatically becaue it isn't an
    exported symbol. You'll have to hardcode what the offset of this
    variable is for each version of ntoskrnl.exe your driver can run
    against. PLEASE don't ship anything that does this. :)

    Denbrook, Craig wrote:

    >
    > -----Original Message-----
    > From: Nick Ryan [mailto:[email protected]]
    >
    >>No, it's not exported from ntoskrnl.exe. I believe there are
    >
    > undocumented Zw* functions to enumerate loaded modules from KM, if that
    > is your intention.
    >
    >
    > -----Original Message-----
    > From: John Szakmeister [mailto:[email protected]]
    >
    >>Yep, ZwQuerySystemInformation, IIRC. It's documented in the NT Native API
    >
    > book.
    >
    >
    > Both are good responses, but unless I am misunderstanding something, the
    > function " ZwQuerySystemInformation" doesn't give the info I am looking for.
    > I used the "SystemModuleInformation" structure with this function and was
    > able to enumerate all kernel modules in the PsLoadedModuleList. However,
    > what I'm trying to find is the actual address of this list. For example, on
    > a local Win2K system, the address is "0x8047FD80" and this seems to hold
    > between boots. I would like to be able to find this address
    > programmatically.
    >
    > Any ideas?
    >
    > Thanks again,
    >
    > Craig Denbrook
    > Sparta, Inc.
    >
    >

    --
    Nick Ryan
    (Microsoft Windows MVP for DDK)
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    You're right. I thought you were looking for a list of modules.

    Sorry, it's like Nick said, it's not exported.

    -John

    > -----Original Message-----
    > From: Denbrook, Craig [mailto:[email protected]]
    > Sent: Monday, January 05, 2004 3:17 PM
    > To: Windows System Software Devs Interest List
    > Subject: RE: [ntdev] PsLoadedModuleList
    >
    >
    >
    >
    > -----Original Message-----
    > From: Nick Ryan [mailto:[email protected]]
    > > No, it's not exported from ntoskrnl.exe. I believe there are
    > undocumented Zw* functions to enumerate loaded modules from
    > KM, if that
    > is your intention.
    > >
    >
    > -----Original Message-----
    > From: John Szakmeister [mailto:[email protected]]
    > > Yep, ZwQuerySystemInformation, IIRC. It's documented in
    > the NT Native
    > > API
    > book.
    > >
    >
    > Both are good responses, but unless I am misunderstanding
    > something, the function " ZwQuerySystemInformation" doesn't
    > give the info I am looking for. I used the
    > "SystemModuleInformation" structure with this function and
    > was able to enumerate all kernel modules in the
    > PsLoadedModuleList. However, what I'm trying to find is the
    > actual address of this list. For example, on a local Win2K
    > system, the address is "0x8047FD80" and this seems to hold
    > between boots. I would like to be able to find this address
    > programmatically.
    >
    > Any ideas?
    >
    > Thanks again,
    >
    > Craig Denbrook
    > Sparta, Inc.
    >
    >
    > ---
    > Questions? First check the Kernel Driver FAQ at
    http://www.osronline.com/article.cfm?id=256

    You are currently subscribed to ntdev as: [email protected] To
    unsubscribe send a blank email to [email protected]
  • JoseJose Member Posts: 5
    There's no safe & reliable way that I know of.

    However, in controlled environments (internal tools) you might wish to risk
    the lack of safety. In this case you can get at the address by walking your
    DriverObject->DriverSection pointer. In NT 4 & later
    DriverObject->DriverSection points to NT's module entry for the system image
    that a DriverObject was created from.

    In current versions new module entries are inserted to the tail of a doubly
    linked list that has PsLoadedModuleList as it's head. Hence, if you do this
    trick in DriverEntry() you can reasonably assume the address of
    PsLoadedModuleList is contained in the FLink pointer for your module entry.

    Standard Disclaimer: This is a hack whose assumptions are subject to change
    at any time and therefore should not be used in production code.

    "Denbrook, Craig" wrote in message
    news:[email protected]
    > Is there a way to programmatically determining the value of
    > "PsLoadedModuleList"? The value is visible in a crash dump, but I would
    > like to determine it from within a driver.
    >
    > TIA,
    >
    > Craig Denbrook
    > Sparta, Inc.
    >
    >
  • MecanikMecanik Member Posts: 41

    Huh... 2004 but we are in 2022. I don't see what's "not reliable" in the below code:

    // Get kernel base address
    
    // Get PsLoadedModuleList address
    for (PLIST_ENTRY pListEntry = pThisModule->InLoadOrderLinks.Flink; pListEntry != &pThisModule->InLoadOrderLinks; pListEntry = pListEntry->Flink)
    {
        // Search for Ntoskrnl entry
        PKLDR_DATA_TABLE_ENTRY pEntry = CONTAINING_RECORD( pListEntry, KLDR_DATA_TABLE_ENTRY, InLoadOrderLinks );
        if (kernelBase == pEntry->DllBase)
        {
            // Ntoskrnl is always first entry in the list
            if ((PVOID)pListEntry->Blink >= pEntry->DllBase && (PUCHAR)pListEntry->Blink < (PUCHAR)pEntry->DllBase + pEntry->SizeOfImage)
            {
                PsLoadedModuleList = pListEntry->Blink;
                break;
            }
        }
    }
    

    A5EF6AC930666A823A905224B7829A417718CA3360E62B9F890B722B20B8BDA5AE187C20E8F7070EADC6B82998999F02

  • Koby_KahaneKoby_Kahane Member Posts: 16

    Before this thread is locked for necroposting, I'll point out that these days you have the documented AuxKlibQueryModuleInformation for doing this.

  • MecanikMecanik Member Posts: 41

    @Koby_Kahane said:
    Before this thread is locked for necroposting, I'll point out that these days you have the documented AuxKlibQueryModuleInformation for doing this.

    Whilst this is indeed existent since Win 200, note the following:

    Drivers must call AuxKlibInitialize before calling AuxKlibQueryModuleInformation.

    Also note the amount of code required for usage. Also note this function allocates pools and calls ZwQuerySystemInformation and so on.

    A5EF6AC930666A823A905224B7829A417718CA3360E62B9F890B722B20B8BDA5AE187C20E8F7070EADC6B82998999F02

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,043

    Before this thread is locked for necroposting

    Time!

    I do not understand why people continue to necropost.

    If you want to comment on a 15 or 20 year old post, START A NEW THREAD, COPY and PASTE the relevant portion from the old thread, and LINK to the rest. Is that so hard? WTF?

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • MecanikMecanik Member Posts: 41
    > @"Peter_Viscarola_(OSR)" said:
    > Time!
    >
    > I do not understand why people continue to necropost.
    >
    > If you want to comment on a 15 or 20 year old post, START A NEW THREAD, COPY and PASTE the relevant portion from the old thread, and LINK to the rest. Is that so hard? WTF?
    >
    > Peter

    Sorry Peter, to my defense I don't even know what "necroposting" is. I hardly am active in any forums.

    A5EF6AC930666A823A905224B7829A417718CA3360E62B9F890B722B20B8BDA5AE187C20E8F7070EADC6B82998999F02

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 9,043
    edited October 23

    @Mecanik ... REALLY? Google is your friend.

    Regardless of the TERM, there IS this in the Community Guidelines, which I know you read prior to posting:

    There are a number of other behaviors that are considered rules of "good conduct" for posting here on the forums. These include:
    ...
    2. Please do not revive "old" threads. Please not reply to threads where the last post is more than a month old. This is referred to as "necroposting." If you have a comment/question/issue that's raised in a "dead" thread, just start a new thread (you can post a link to the old thread if you want) and ask your question there.

    (Thank you @Mark_Roddy)

    Peter Viscarola
    OSR
    @OSRDrivers

This discussion has been closed.

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 30 January 2023 Live, Online
Developing Minifilters 20 March 2023 Live, Online
Writing WDF Drivers TBD 2023 Live, Online
Internals & Software Drivers 17 April 2023 Live, Online