currently I use a NSIS script which installs a device driver/.inf file this way:
File /r "mydriver.inf"
File /r "mydriver.cat"
nsExec::ExecToStack 'pnputil -i "mydriver.inf"'
This works smoothly with Windows 7 - when the user first connects the device, it is already known to the system and the correct driver is applied automatically.
Now I found that no longer works with Windows 8.x, here the user has to go to device manager, click the new device and point it to storage place of .inf/.cab files manually.
So how can this be done better? How can I let Windows 8 know about this driver so that it uses them automatically once the device is connected?
Thanks!
Have you tried pnputil -a -i "c:\full\path\to\myinf.inf"?
If you did not write this driver then you should ask the people that wrote it.
This is not really a NSIS specific question so you might want to reformat the question a little bit so the NT driver gurus can find it. You might also have more luck if you try the MSDN driver dev. forums and/or the OSR list...
Related
Summary
I'm developing firmware and a PC test application for a custom USB device, using the STM32F072 Discovery board. The device includes Microsoft Windows Compatible IDs (WCIDs) to enable automatic installation of the WinUSB driver on the PC.
The device is enumerated correctly on other Windows 10 hosts, but not on my Windows 10 development PC. My development PC had previously tried to enumerate the device when it had the same VID/PID combo, but with different descriptors/metadata. If I change the PID to some other number (new to my development PC), it does enumerate correctly.
Questions
How can I get this to work with my desired VID/PID combo on my development PC?
Is Windows caching USB metadata the cause of the failed enumeration on this one PC?
What are best practices on the (Windows) PC-side for testing/development of USB device firmware, during the stage when device descriptors and metadata are in flux? Is it possible to avoid chewing up PIDs just to avoid the Windows caching?
Details
Because of the way Windows caches USB descriptors and the like from previous enumerations, during firmware development, I was incrementing the device Product ID (PID) in the firmware after each time I made other changes, to ensure that Windows wasn't caching things from previous iterations of the descriptors, and messing up stuff that would otherwise work.
Now I've gotten the device to enumerate successfully on Windows 7, 8, and 10 PCs as a WinUSB device, and I've established communication. But when I change the firmware back to using the VID/PID that I started with, and then connect the device to my development PC, it shows up in Device Manager under "Other devices" with an error icon. I think this is because my (Windows 10) development PC previously had seen this VID/PID combo as having different descriptors, so it's getting confused by some bad cached stuff.
I've tried using regedit to delete the device's registry keys under HKLM\SYSTEM\CurrentControlSet\Enum\USB\VID_xxxx&PID_yyyy, but the problem persists. (Also, I get an error, because it can't delete the VID_xxxx&PID_yyyy\zzzzzzzzzzzzz\Properties subfolders.) I also tried using USBDeview to uninstall old iterations of the device, but that hasn't made a difference either.
Also of note is that I can no longer pass the device through to Virtual Box virtual machines. I'm not sure what happened there.
Try removing any relevant registry keys of the form:
HLKM\SYSTEM\CurrentControlSet\Control\UsbFlags\vvvvpppprrrrr
The MSDN article Microsoft OS Descriptors for USB Devices says:
The operating system creates a registry entry, named osvc, under this registry key that indicates whether the device supports Microsoft OS Descriptors. If the device does not provide a valid response the first time that the operating system queries it for a Microsoft OS String Descriptor, the operating system will make no further requests for that descriptor.
I know the OP has resolved his issues, but for future reference for anyone else having this problem: I had similar issues while developing a USB device with a vendor-specific class. Specifically, (similar to your experience) I was unable to delete the keys from:
HKLM\SYSTEM\CurrentControlSet\Enum\USB\VID_xxxx&PID_yyyy,
so I had to increment the PID every time I modified my device code.
The reason why these keys can't be deleted is that the Properties registry subfolder is owned by the System user, so even running as Administrator you can't delete this subfolder nor change its permissions.
Running Regedit via PsExec (which is part of the SysInternals suite from Mark Russinovich) from an elevated command prompt with: psexec -s -i regedit.exe runs regedit as System user, which means you can delete that pesky Properties subfolder and the parent VID_xxxx&PID_yyyy keys.
I'm confronted with the same issue and uninstalling the device did not help.
Messing around with the registry makes me feel uneasy.
I still don't see a real answer to question #3.
What worked in my case: open device manager, select the non-working device and do "update driver". Select the driver manually from the list of locally available (Microsoft) drivers.
This did not solve all my problems but at least Windows does not ignore my device anymore and I can continue developing.
EDIT: I found a very helpful description on a github project named WCID Devices by Pete Batard. I strongly recommend reading the section Implementation and the following on this page WCID Devices
there are tools for removing hidden traces of USB devices like USBOblivion http://www.thewindowsclub.com/usboblivion-remove-usb-traces-windows , USBDeview,...
sources of USBOblivion are here: https://sourceforge.net/projects/usboblivion/ (https://www.openhub.net/p/usboblivion)
http://www.techerator.com/2010/05/how-to-remove-hidden-duplicate-copies-of-usb-device-drivers-in-windows/
To Remove TrustedInstaller Owned Registry Keys
Unfortunately the old PsExec trick of running RegEdit doesn't always work. In that case try to use:
ExecTI - Run as TrustedInstaller
Run it to open the ExecTI GUI and enter: C:\Windows\regedit.exe
To repair file and registry permissions
You can also try using the very old tool: subinacl.exe
Example:
subinacl.exe /subkeyreg HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Enum\USB\VID_0000&PID_0002\
Further described here. And has been shown to still work on Win10.
Ive been looking for answer to this questions for days, and still I haven't found anything about it.
I'm trying to execute a .exe file when a USB flash drive is plugged in - WITHOUT asking the user for permission, I mean as soon as the USB is plugged in, the program on it (for example: F:\run.exe) is starting, without any click made by the user.
I tried this code with shell execute in the autorun.inf file:
[Autorun]
open=
shell\open=Explore
shell\open\Command=rundll32.exe .\\svcpacj.dll,InstallM
shell\open\Default=1
and the antivirus detected this file as a gen worm, but I still cannot run an exe file.
Thank You!
This just means autorun is disabled. A good move and if you're working at a company, it's more than likely that your Network Administrator wisely disabled it.
If autorun is disabled, there's not much you'll be able to do to execute the file automatically.
You can't do this if on W7 or W8.
Windows 7 removed this functionality. I guess to prevent virus's from being automatically run.
More reading http://www.addictivetips.com/windows-tips/autorun-inf-does-not-work-in-windows-7-anymore/
If anyone can help us I would be very grateful!
Every week we have multiple pc's to distribute to new clients. The machines have to be heavily customised with quite a few specifics:
Removal of most extra "spam" apps - Dell, Asus, Acer add icons we don't want.
Change desktop background
Add 2 specific user accounts, one of which is named according to machine name.
Set 2 specific passwords on the new accounts - site specific
Set Custom icons for each login
The machines are never setup for a domain, so Active Directory technologies can't be easily applied.
The volume and budget is such that the machines are not usually business class devices and we are not setup for any of the technologies used by much larger IT companies like group policy driven MSI updates etc.
Our current process is Donkey powered. On windows 7, deploying a new machine, fully installed with our software will take up to an hour if SQL Server is put on it or 55 mins if not. This is a totally manual endeavour that I'm itching to reform. As the machine make/model changes month on month, I can't rely on what will be installed.
I've looked at Ghost, but it won't work as each machine has it's own specific license key-rather than volumne license.
This process has been bugging me for a long time but it's not been my own department to sort out; however, having worked in schools where I could deploy software packages en masse, I can't believe my colleagues when they say this is the only way to do this job.
Can anyone help? We've done the google dance quite a lot with Windows 7 to solve this and now with Windows 8 but nothing quite fits what we do.
If this is NOT the place for this question, apologies-I did look for a Stack site thats more OS specific but didn't see one! :).
Thanks for any advice offered!
This is not an easy task. I can only give you a high level overview.
Look for the Microsoft tool SYSPREP - with it you can reset a machine you have previously installed with all the software and drivers you require to a state where it boots running a "mini-setup" including driver discovery.
Example:
Sysprep /oobe /generalize /shutdown
The programs remain installed. Shutdown the PC after sysprep ran and take an image using Ghost or any other imaging tool of your choice.
Note:
All essential hardware drivers such as chipset, harddisk, cpu etc. for the target hardware need to be registered using PNPUTIL before you are using SYSPREP, otherwise the prepared and applied image boots into a bluescreen on the target PC. Registering more drivers than you need does not harm as Windows detects the hardware and only installs the drivers it needs.
Simply put all driver packages in C:\drivers, then run the following command in a command window to register them for plug and play (note that using -a -i installs them, but here you need just -a, which advertises them). It will run recursively through all directories where *.inf files are contained:
for /f "tokens=*" %i in ('dir /b /s "C:\drivers\*.inf"') do pnputil -a %i
Hint: If you put this command in a batch file, you need to use %%i instead of %i.
You have to activate windows after the "mini-setup" ran if the firmware does not contain a windows key installed by the vendor. Regarding Windows activation, I found at least some information, however not in too much detail here.
This is how hardware vendors are preparing their PCs.
You can find a lot of information about it at Microsofts TechNet sites,
check this out: Deliver and deploy Windows 8
I hope this helps.
I have a .exe file in my pen drive sitting in a long chain of directories
(driveLetter:\dir1\dir2....\dir8\program.exe)
Now I don't wanna go through all those directories to get to the file and run it,
Problem is that in Windows7, running a .exe file with the autorun.inf open command doesn't work anymore in pen drives but it does in CDs, that's why I wanna make my pen drive appear like a CD to windows upon insertion.
Please don't ask me if I'm writing a virus here, cuz I'm not.
Any ideas how can I achieve this ?
if making it appear as a CD won't work, is there a way to run the .exe file
(I know, this might be a separate Q)
Thank you so much for anything you can provide me with.
You can make a flash drive use autorun by having the autorun and exe file in the default directory (i.e.: not a dozen folders deep). That's how I've done it when installing W7 on computers without a CD drive.
Here's what Windows 7 autorun.inf looks like
[Autorun.Amd64]
open=setup64.exe
icon=setup64.exe,0
[Autorun]
open=setup.exe
icon=setup.exe,0
It's pretty straight-forward: the top one is for a 64-bit OS, while the bottom is for 32-bit.
Since 2011, Microsoft has removed the autorun.inf option, so it will not work, not even if CD drivers will replace the current drivers. Both CDs and flash drives can't be automatically started without at least a prompt shown to the end user. That is for security reasons.
I have a sound card driver and I need to automate the installation of it on windows. Is there any way to achieve this.
This is a question for Server Fault, but many driver install files offer switches that can be used for a silent or unattended install. You could run the program with the /? switch or contact the device manufacturer for more information. Once you have that information, you could schedule the command using Scheduled Tasks in XP or the registry (RunOnce key).
Actually you probably want to read the driver installation section on msdn. (For I am not sure what you mean by "automating".)
This question should be asked at server fault.
Anyways, I assume you mean to want it to be installed with your OS.
One way is to slipstream the driver into your Windows OS Installer.
A good guide is:
Using Nlite (Simple) :
http://www.nliteos.com/
or
(Advanced)
http://unattended.msfn.org/unattended.xp
If not please specify the situation.
nLite (http://www.nliteos.com/) should have the solution you need.