For previous versions of Windows, DefineDosDevice can be used to “broadcast” a drive letter to Explorer, but this doesn’t seem to work on Vista. Other programs starting under the same administrative account can see the drive letter but Explorer cannot. Is there any trick to get this to work? Thanks.
Are you calling DefineDosDevice from an elevated application?
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Monday, March 30, 2009 1:07 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] DefineDosDevice and Vista
For previous versions of Windows, DefineDosDevice can be used to “broadcast” a drive letter to Explorer, but this doesn’t seem to work on Vista. Other programs starting under the same administrative account can see the drive letter but Explorer cannot. Is there any trick to get this to work? Thanks.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
MSDN:
Starting with Windows XP, this function creates a device name for a caller that is not running in
the LocalSystem context in its own Local MS-DOS device namespace. If the caller is running in the
LocalSystem context, the function creates the device name in the Global MS-DOS device namespace. For
more information, see Defining an MS DOS Device Name.
I think that’s the root of your problem.
Good luck,
mm
xxxxx@yahoo.com wrote:
For previous versions of Windows, DefineDosDevice can be used to “broadcast” a drive letter to Explorer, but this doesn’t seem to work on Vista.
Other programs starting under the same administrative account can see the drive letter but Explorer
cannot. Is there any trick to get this to work? Thanks.
Doron,
DefineDosDevice is called in an elevated console application. The mounting code before the call requires administrative rights.
MM,
I though the same namespace should be visible to all apps running under the same login session. In XP and 2003, the drive letter always shows up in Explorer after the call.
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Monday, March 30, 2009 10:53 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DefineDosDevice and VistaI though the same namespace should be visible to all apps
running under the same login session.
That’s right. Your problem is that elevated app runs under different
login session. You can use WibObj to verify it.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
When you elevate, you are in a different session. Just try running net use * \server\share in an elevated cmd prompt and then run net use in a non elevated prompt. You will not see the mapping
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Monday, March 30, 2009 1:53 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DefineDosDevice and Vista
Doron,
DefineDosDevice is called in an elevated console application. The mounting code before the call requires administrative rights.
MM,
I though the same namespace should be visible to all apps running under the same login session. In XP and 2003, the drive letter always shows up in Explorer after the call.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
I made the call in a non-elevated app and the drive letter shows up in Explorer. Thanks.
This is not a kernel programming issue, but I cannot figure out what to do next. My app will need to be elevated to mount a volume, then it will need to be de-elevated to call DefineDosDevice. But there seem to be no way to lower the privilege level when the app is running in an elevated state.
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Tuesday, March 31, 2009 7:35 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DefineDosDevice and VistaThis is not a kernel programming issue, but I cannot figure
out what to do next. My app will need to be elevated to
mount a volume, then it will need to be de-elevated to call
DefineDosDevice. But there seem to be no way to lower the
privilege level when the app is running in an elevated state.
What about opposite order? DefineDosDevice just creates a symbolic link.
I’m not sure if there is any check for target validity. You can try
create driver letter at first and then mount the volume. Of course, if
mount fails, you’d have a problem.
The other possibility is to create the symbolic link in correct session
manually. Elevated app should have enough rights for it.
Both ways are a bit ugly, maybe somebody will have a simpler idea.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
“Michal Vodicka” wrote:
> What about opposite order? DefineDosDevice just creates a symbolic link.
> I’m not sure if there is any check for target validity. You can try
> create driver letter at first and then mount the volume. Of course, if
> mount fails, you’d have a problem.
The thought that comes to mind for me is to have my application run
non-elevated in the calling user’s actual session. i.e. Manifest of
the application would specify “asInvoker”.
Once my application needs to mount the physical volume, if I determine
the current user session doesn’t hold sufficient permissions to
perform this operation, I would re-spawn my same application .exe as
elevated (e.g. via the ShellExecuteEx “runAs” verb), but with command
line switches or other inter-process communication to indicate just
the physical volume mounting operation needs to be performed.
The non-elevated instance would wait on a result from the elevated
process instance, and if success is indicated would then define the
DosDevice for the current (non-elevated) user logon session.
Alan Adams
Chu,
You can consider COM elevation moniker.
http://msdn.microsoft.com/en-us/library/ms679687(VS.85).aspx
Basically, put all your mounting code in a separate function.
Before calling the mounting code, check if the user is admin and if he is not, you could check whether UAC is enabled. If the UAC is enabled, simply call the function from the com interface, and that should do the trick. Your app would not need to be elevated, only the function would run elevated.
If you need an example, you could check out TrueCrypt’s code for formatting a volume.
The specific code is in Format.c and it reads:
if (!IsAdmin () && IsUacSupported ())
retCode = UacFormatNtfs (volParams->hwndDlg, driveNo, volParams->clusterSize);
else
retCode = FormatNtfs (driveNo, volParams->clusterSize);
//after this, do the DefineDosDevice
Achintya