Hi,
We sell a USB device with a dedicated DLL and 32 bit kernel driver. For 64
bit, and as an alternative for 32 bit Windows, we use the winusb driver.
We also provide sample programs for many different development environments.
On 32 bits Windows 7, for some reason, the MS VC++2008 and VC#2008 samples
need to be run with administrator rights to be able to use winusb, but the
Delphi and C++ Builder samples using the same DLL do NOT need to. This is a
problem when the UAC setting is in the default position, as even a user in
the administrator group will then run into this.
Any idea as to what causes this difference?
What would be the best way to solve this (apart from switching off UAC)?
Winusb being a user mode driver, is it possible to set some
privileges/permissions ?
Regards, Matt
xxxxx@avantes.com wrote:
We sell a USB device with a dedicated DLL and 32 bit kernel driver. For 64
bit, and as an alternative for 32 bit Windows, we use the winusb driver.
We also provide sample programs for many different development environments.
On 32 bits Windows 7, for some reason, the MS VC++2008 and VC#2008 samples
need to be run with administrator rights to be able to use winusb, but the
Delphi and C++ Builder samples using the same DLL do NOT need to. This is a
problem when the UAC setting is in the default position, as even a user in
the administrator group will then run into this.
Any idea as to what causes this difference?
Are you aware that you can add a chunk to your manifest that will
automatically elevate your application when it is run?
http://msdn.microsoft.com/en-us/library/bb756929.aspx
It may be that’s what Delphi is doing.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> Are you aware that you can add a chunk to your manifest that will
automatically elevate your application when it is run?
http://msdn.microsoft.com/en-us/library/bb756929.aspx
This will ask a dialog, at least on default UAC settings on pre-Win7.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
You can put a security descriptor for the device in the INF file for WinUsb driver. See AddReg, HKR,Security value. I think WinUsb may be using IOCTLs that require WRITE access, which is not granted by default, unless you are an elevated administrator.
Hi,
I understand that it is possible to make your program run with administrator rights, with ‘Run as administrator’, or by embedding the correct manifest.
My point is that on W7-x86 some demos that use winusb can run as standard user, while others need more rights, the ones written in VB, VC# and VC++/Qt4 to be precise.
On W7-x64, they all run as standard user, none of these need more rights (same executable, same DLL)
Looks like a problem in the 32 bit version of winusb to me. I am using the version from the 7600.16385.0 WinDDK
Regards, Matt
Requiring your applications to run as an administrator is an approach Microsoft is trying to discourage, with varying success. Just don’t do it. Design it right. If an user needs to access your device, change the device security descriptor, but DON’T require the user to run as administrator. Please.
wrote in message news:xxxxx@ntdev…
> Requiring your applications to run as an administrator is an approach
> Microsoft is trying to discourage, with varying success. Just don’t do it.
> Design it right. If an user needs to access your device, change the device
> security descriptor, but DON’T require the user to run as administrator.
> Please.
>
This is exactly what the OP wants. The question is why this does not work on
certain OS or winusb version (1.7 vs 1.9?)
–pa
What CreateFile calls you’re using to get a handle to the device in your WinUsb samples?
Hi Alex,
The CreateFile call (located in a DLL, common to all samples) is:
m_hDeviceHandle = CreateFile(
m_DevicePath, // filename
GENERIC_WRITE | GENERIC_READ, // access
FILE_SHARE_WRITE | FILE_SHARE_READ, // sharing
NULL, // security: none
OPEN_EXISTING, // disposition:
FILE_ATTRIBUTE_NORMAL | FILE_FLAG_OVERLAPPED, // file attributes
NULL // template file
);
It comes straight from the Microsoft document “How to Use WinUSB to Communicate with a USB Device”
Regards, Matt
In your INF file, in AddReg section referenced by your .HW section, add the following string:
HKR,Security,“D:P(A;;GA;;;SY)(A;;GRGWGX;;;BA)(A;;GRGWGX;;;WD)(A;;GRGWGX;;;RC)”
You’ll have to reinstall the driver, for the INF to take effect.
Hi,
Think I found the problem, and it is only indirectly related with the device driver. A registry key was read without specifying the security access level. Apparently when the default level is too high, some environments will give at least reading access, and others will give no access at all.
Thank you for your suggestions,
Regards, Matt
Would you be willing to post more details in case someone else
encounters the same issue? Such as what component is performing this
read and what was your fix?
On 1/24/2011 2:13 AM, xxxxx@avantes.com wrote:
Hi,
Think I found the problem, and it is only indirectly related with the device driver. A registry key was read without specifying the security access level. Apparently when the default level is too high, some environments will give at least reading access, and others will give no access at all.
Thank you for your suggestions,
Regards, Matt
Hi Philip,
I am a bit reluctant to post all details, as it turned out not to be a driver problem. The issue was with use of the TRegistry component in Borland C++ Builder. In version 5, the sample program for this did not contain setting the Access property, thereby relying on the setting of this property in the constructor with a value of KEY_ALL_ACCESS.
Now, reading a registry key like this with standard user rights works just fine in pre-Windows 7 versions of Windows, and it still works fine there with a large number of compilers, like C++ Builder, or the VS2005 compilers.
Not so with e.g. the VC#2008 compiler. Here you will have to specify the Access property with a value of KEY_READ, or the reading of the registry value will fail.
I checked the documentation of a newer version of C++ Builder (2009), and here it is indeed stated that the Access property must be set first, and with a value that is not too high (compared with the user rights).
So obviously, some things have changed here. We probably should have upgraded before being overtaken.
Regards, Matt
“Now, reading a registry key like this with standard user rights works just fine
in pre-Windows 7 versions of Windows”.
It would only work fine in Win9x, which is, thankfully, dead by now.
It would not work in all pre-Win7 NT-based Windows versions. It’s just the people didn’t know better than be logged on as Administrator. Microsoft didn’t tell them otherwise, and that become the biggest hit for Windows security reputation.