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


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:

Before Posting...

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


dev098311dev098311 Member Posts: 6


I am working on a driver component which will take a DOS path (i.e. C:\Windows\foo.exe) and convert it to the NT/Device path (i.e. \Device\HardDiskVolume3\Windows\foo.exe). To do this, I am trying to use the standard ZwOpenSymbolicLinkObject -> ZwQuerySymbolicLinkObject flow. When calling ZwOpenSymbolicLinkObject, I am getting a STATUS_OBJECT_TYPE_MISMATCH error.

I have minimized the issue to demonstrate what is going on in the following code snippet. Please note that this is not my production code so there is no error checking, etc.

NTSTATUS status;
HANDLE hSymlink;

// Initialize the name with some value
RtlInitUnicodeString(&symlinkName, L"\??\C:\Windows\explorer.exe");

InitializeObjectAttributes(&attributes, &symlinkName, OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE, NULL, NULL);

status = ZwOpenSymbolicLinkObject(&hSymlink, GENERIC_READ, &attributes);

// At this point, status is 0xC0000024

< snip >

This seems like the correct way to call this API based on public examples and other posts on this forum, but I can't seem to figure out what is going on. Any help or pointers would be much appreciated.



  • gordon_lewisgordon_lewis Member Posts: 9
    edited September 19

    I am not certain if the post removed the double backslashes in that post or not. Maybe because explorer.exe is not a symbolic link.

  • dev098311dev098311 Member Posts: 6

    You're correct, it should be \\??\\C:\Windows\explorer.exe. Sorry for the confusion.

    I've conducted some additional testing and the only way I can get it to resolve is by using the exact name of the symlink in object manager (i.e. \??\C:) with no path/file suffixed. Ideally, I'd like to avoid breaking paths apart and shimming in device names but I'm pretty lost at this point.

  • dev098311dev098311 Member Posts: 6

    Following up in the event that someone in the future comes across this post. I was unable to find a native way to do this so I had to split the path, resolve the symlink, and then reconstitute the path. Roughly, this process looks like:

    1. Use FsRtlDissectName to split the path into parts
    2. Prepend \??\ to the first part, making it something like \??\C:
    3. Resolve this symlink using the standard ZwOpenSymbolicLinkObject->ZwQuerySymbolicLinkObject workflow
    4. Combine the resolved symlink with the second file part from the first step, adding a path delimiter between them

    Here's hoping that MSFT will add DOS to NT path canonicalization in the future, but for now this seems to be what we're stuck with.

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 450
    via Email
    Open the target without open symlink or stop on reparse point flags.
    Query the name from the filesystem.

    That is what we do, since Filter Manager decided to break name query on
    cross volume symlinks in Win10 1703/9 :(

    Kind regards, Dejan.
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!
Internals & Software Drivers 15 November 2021 Live, Online
Writing WDF Drivers 24 January 2022 Live, Online
Developing Minifilters 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online