QueryDosDevice function (Windows)

Switch View :
ScriptFree
QueryDosDevice function

Applies to: desktop apps only

Retrieves information about MS-DOS device names. The function can obtain the current mapping for a particular MS-DOS device name. The function can also obtain a list of all existing MS-DOS device names.

MS-DOS device names are stored as junctions in the object namespace. The code that converts an MS-DOS path into a corresponding path uses these junctions to map MS-DOS devices and drive letters. The QueryDosDevice function enables an application to query the names of the junctions used to implement the MS-DOS device namespace as well as the value of each specific junction.

Syntax

DWORD WINAPI QueryDosDevice(
  __in_opt  LPCTSTR lpDeviceName,
  __out     LPTSTR lpTargetPath,
  __in      DWORD ucchMax
);

Parameters

lpDeviceName [in, optional]

An MS-DOS device name string specifying the target of the query. The device name cannot have a trailing backslash; for example, use "C:", not "C:\".

This parameter can be NULL. In that case, the QueryDosDevice function will store a list of all existing MS-DOS device names into the buffer pointed to by lpTargetPath.

lpTargetPath [out]

A pointer to a buffer that will receive the result of the query. The function fills this buffer with one or more null-terminated strings. The final null-terminated string is followed by an additional NULL.

If lpDeviceName is non-NULL, the function retrieves information about the particular MS-DOS device specified by lpDeviceName. The first null-terminated string stored into the buffer is the current mapping for the device. The other null-terminated strings represent undeleted prior mappings for the device.

If lpDeviceName is NULL, the function retrieves a list of all existing MS-DOS device names. Each null-terminated string stored into the buffer is the name of an existing MS-DOS device, for example, \Device\HarddiskVolume1 or \Device\Floppy0.

ucchMax [in]

The maximum number of TCHARs that can be stored into the buffer pointed to by lpTargetPath.

Return value

If the function succeeds, the return value is the number of TCHARs stored into the buffer pointed to by lpTargetPath.

If the function fails, the return value is zero. To get extended error information, call GetLastError.

If the buffer is too small, the function fails and the last error code is ERROR_INSUFFICIENT_BUFFER.

Remarks

The DefineDosDevice function enables an application to create and modify the junctions used to implement the MS-DOS device namespace.

Windows Server 2003 and Windows XP:  QueryDosDevice first searches the Local MS-DOS Device namespace for the specified device name. If the device name is not found, the function will then search the Global MS-DOS Device namespace.

When all existing MS-DOS device names are queried, the list of device names that are returned is dependent on whether it is running in the LocalSystem context. If so, only the device names included in the Global MS-DOS Device namespace will be returned. If not, a concatenation of the device names in the Global and Local MS-DOS Device namespaces will be returned. If a device name exists in both namespaces, QueryDosDevice will return the entry in the Local MS-DOS Device namespace.

For more information on the Global and Local MS-DOS Device namespaces and changes to the accessibility of MS-DOS device names, see Defining an MS DOS Device Name.

Examples

For an example, see Obtaining a File Name From a File Handle or Displaying Volume Paths.

Requirements

Minimum supported client

Windows XP

Minimum supported server

Windows Server 2003

Header

WinBase.h (include Windows.h)

Library

Kernel32.lib

DLL

Kernel32.dll

Unicode and ANSI names

QueryDosDeviceW (Unicode) and QueryDosDeviceA (ANSI)

See also

DefineDosDevice
Volume Management Functions

 

 

Send comments about this topic to Microsoft

Build date: 4/17/2012

Community Content

steveren
\Device\LanmanRedirector and \Device\Mup
These are not actually different. In WinXP, \Device\Mup didn't exist and \Device\LanmanRedirector was a real device. In Win7 (and Vista?), it's a symbolic link to \Device\Mup. You can follow the link chain with the native functions NtOpenSymbolicLinkObject and NtQuerySymbolicLinkObject.

eriklitze
QueryDosDevice and Network locations
The QueryDosDevice() function can only be used to effectively translate *LOCAL device drives only. Consider the following scenerio.

1.

The prefered way for translation of device paths to drive letter is using FindFirstVolume and FindNextVolume. These return local GUID drive paths but they skip network mapped drives. Thus no network drive would be queried only local drives.

2.

Using GetLogicalDriveStrings() and pass each drive letter to QueryDosDevice function. Local drives letters passed into QueryDosDevice() translate successfully, when you hit a drive letter that is considered a network mapped drive you will get the following output \Device\LanmanRedirector\;Z:0000000000017615\192.168.0.25\bogusshare . The problem then is that output from functions that return device paths such as (GetMappedFileName, NtQueryObject) return different output suchs as \Device\Mup\192.168.0.25\bogusshare . If you would attempt to take the QueryDosDevice() buffer and translate this it would fail because they aren't consistant with each other.


3.
If your application is running on Vista or later it's highly recommended that you use GetFinalPathNameByHandleW this function is capable of returning the correct format given a handle.
\UNC\192.168.0.25\bogusshare


Conclusion:

You can't effectively use QueryDosDevice to translate network related device paths coming from functions that return device path information because these function return completley different device paths. It's highly recommended that you use the first scenerio above (FindFirstVolume,FindNextVolume) which would skip network paths and leave the functions such as (GetMappedFileName, NtQueryObject) return whatever they place into the buffer.

Q33NY
QueryDosDeviceW
When using the Wide version of this be sure to allocate twice as much space in the buffer than you pass to ucchMax.

Example:

If the buffer is 8192 bytes then ucchMax should be 4092 bytes.


This is a little bit missleading....when using the W version the buffer is a wchar_t* and the ucchMax is the number of wchar_t elements, same as for the A version. It would be best for the coder to use the argument types defined in the header: LPCTSTR(especially if using the macro "QueryDosDevice") and not in BYTE*, to avoid any char - wchar_t confusions which may even crash the app; or use one of the functions exported by kernel32 directly - this way the app won't depend on the UNICODE macro.

efotinis
Return Value under Windows 2000

[originally asked by Peter Hull <http://msdn.microsoft.com/en-us/library/user-224915.aspx>]

  • Can you clarify - if the buffer is too small the return value is ucchMax for Windows 2000 and 0 for all other versions? So it is always necessary to check the GetLastError() value to see if it succeeded or not?

After some testing on Windows 2000 SP4 (5.00.2195) it seems that QueryDosDevice() returns 0 on failure, just like in all the other Windows versions.


eriklitze
Buffer
If you pass lpDeviceName NULL value then a reasonable buffer size to avoid an error would be 65536.(64KB)
If you pass lpDeviceName a drive letter a reasonable buffer size would be 1024.(1KB)


Aaron Ballman
Different failure values
Under what circumstances will this function fail with an ERROR_NO_SYSTEM_RESOURCES value from GetLastError? I am allocating a buffer using malloc (and the resulting buffer is valid), and yet this function fails with that error code, seemingly at random.