I'm following a video tutorial that covers developing WDM drivers and I've managed to put together a very barebones driver that doesn't really do anything other than print when it's loaded or unloaded. I did not make any modifications to the INF file generated by visual studio, and have built the driver successfully under Debug x64. Im slight confused by the output of the build, because the resulting driver and INF file are generated in two places:
Under \ProjectName\x64\Debug along with the pdb and certificate
Under \ProjectName\x64\Debug\ProjectName with only a cat file
Attemnpting to install from teh first location gives me the error:
The third-party INF does not contain digital signature information.
And from the second I get:
A problem was encountered while attempting to add the driver to the store.
I've tried installing the certificate, but it doesn't seem to work and there's no information in the Event Log. I get this same error, attempting to install on my local machine and on a VM both running Win 10 x64.
I guess I have 2 question: for starters, why do two driver / INF pairs get generated, which is the right one for me to use? And secondly, what do I need to do / fix / change /etc. so that I can install my locally developed driver on my machine>
Related
Forgive my basic questions, firmware guy here. I have been "gifted" ownership of the driver for a HID device. The current driver is outdated in that it no longer supports the full range of USB pids that this product line supports. I have all of the source code, including a simple text file that includes the list of supported PIDs. I added the new range, and executed several Perl scripts with titles like "IncrementVersions", "BuildINFs" and "BuildWindowsDrivers". I can share these scripts if they're helpful.
The upshot is I seem to have some .inf files that were updated correctly: were up-rev'd, and contain the new range of USB PIDs. But if I right click on one and select "Install", I get a message that says "The system cannot find the file specified". Similalrly, if I got into Dev Man and try to update the driver, Dev Man says I'm already using the best driver for that device.
I do notice that previous versions of this driver were built into setup.exe files. I thought I could install an .inf file directly, but perhaps these setup wrappers contain some necessary functionality? How can I create a setup.exe file from an .inf?
Is any of this helpful in pointing me toward what I might be doing wrong? What can I share that would provide more useful info?
You can install INF files directly but there are three important things to know:
The INF file needs a DefaultInstall section with a line like "CopyINF=your_inf_name.inf". (Actually I think it's not needed on Windows 10 maybe).
You need a CatalogFile directive that refers to a .cat file in the same directory that you have properly signed with your code signing certificate.
You need to right-click on the INF file in Windows Explorer and click "Install" to actually install it.
Since the system is complaining about a missing file, of course you should also read your INF file carefully and make sure all the files it refers to exist somewhere where Windows knows how to find them.
I am developing a kernel mode driver for Windows 10 and I am stuck on the service start it always gave me this error:
"0x2 The system cannot find the path specified"
to install it I have tried by the following ways:
Using "sc create svname binpath="pathtodriver" type=kernel".
Creating a service from my c++ a`` with CreateService API and Kernel Mode flag.
Both return the same error for me, but here's the most stranger thing looks I have a desktop (from I am writing this and I develop my apps, study etc) in this desktop I can install the driver without any problem using both ways, Now on my laptop what I use to test some of my software it installed the first time and after that I couldn't start anymore the driver service, the path is correct
I have checked it a lot of times and tried almost everything.
Also I have other Kernel Mode driver which loads on both computers anytime without any problem its stranger really i have been trying all...
What I have tried to solve this problem:
Deleting the service from sc using "sc delete svname".
Deleting the service directly from registry.
Restoring registry.
Repairing windows.
Installing almost every Visual C++ Runtimes.
Install the driver with another service name, file name and different path.
Nothing of the list solves my problem.
(I am on Test Signing to test my driver without DSE)
EDIT: Solved was my DriverEntry it was returning 0x2 cause it was not compatible with all optical devices.
To install a driver, you typically send the command:
DefaultInstall 128 {inf path}
to the InstallHinfSection via direct call or RunDLL.
This works wonderfully. I can install my driver anywhere (including 64-bit Win 2008 R2, which means I've got all the code signing right too).
HOWEVER, the above fails when launched from a Windows service. I've read about service vs client installs, and hoped I had met all the requirements for a silent service install (built a .CAT file, it is signed along with the driver, etc).
But no dice - it just fails. Comparing the errors in SetupAPI.log between an interactive install and the install from the service doesn't show any differences (other than the interactive takes the steps of copying the driver file and succeeds, where the other doesn't).
The driver itself is not in use (my service is the only one that uses it). Is there ANY way for a service to silently update a driver without requiring user interaction?
I called Microsoft and discussed this with a support engineer.
Turns out that using DefaultInstall with InstallHinfSection is somewhat obsolete, but still works. And it just happens to work without prompting the user if the driver is signed by a certificate that they recognize because DefaultInstall is 'dumb'. Yet the driver itself is still allowed to launch because it's cross-signed with the Microsoft cert. A nice little loop-hole I guess. The trick is it has to be installed by a service that is set to Interact with Desktop (a requirement). Using something like PsExec or RemCom is a way to do this if your service isn't currently running in that way.
In the future, this might not continue to work. At that point, get the driver's .cat file into the Windows\System32\Catroot{F7... folder but it can't just be copied directly in -- there is an API.
If the .cat was put in first, then the driver theoretically shouldn't need to prompt to ask if the certificate for the driver is acceptable to the user, because catroot is the 'acceptable to the user' list of certs and drivers.
Also, having the catalog file installed before attempting the driver install might help since the catalog contains the security certificate that the driver will present (though not necessarily in this case -- but it might help in the future (and possibly with Win 2003)
Basically the support engineer was surprised this worked at all and we went around and around on how it might be working... Hopefully this helps someone else.
We have a usb device and the drivers (.inf, libusb.dll, libusb.sys) and can install it using Windows' Device Installation Wizard (by pointing to the .inf file). However, we need to install the drivers without using the wizard (passively, so the user doesn't need to do anything). Does anyone know how this can be achieved?
You added the "installer" tag, so I'm assuming you're talking about some kind of installation package, like Windows Installer, InstallShield InstallScript, etc.
If that's the case, you should probably use Microsoft's DIFx framework.
DIFx makes it easier for you to create
high-quality driver packages,
customize the installation of driver
packages, allow the installation of
driver packages in combination with
application software, and use the
standard Windows APIs and installation
tools. DIFx also makes it easier for
end users to diagnose device and
driver problems. End users can be
confident that, if necessary, drivers
can be uninstalled or rolled back.
I've used DIFx from both Windows Installer-based installs and InstallScript installs. Very user-friendly, easy to debug, and effective.
My colleague came up with an answer that is working very well. It appears that, unless you hardware/driver combination is WHQL signed, the Add New Hardware Wizard will always appear in Win XP. However, with the following method it is possible to have the "Search" button in the wizard find your driver automatically. In Windows 7, there is no prompt and the device installs just fine. You'll need to watch out on 64-bit machines, though, as they have much stricter signing enforcement.
So here is the relevant excerpt from the whole document:
Use the DIFxAPi merge module. (Read a good introduction to drivers in Windows, the use of INF files, and DIFxAPP.) The DIFxAPI merge module is included in the WDK in the ‘WDDK//redist\DIFx\DIFxApp\MergeModule\’ directory. The merge module can be included in an MSI package and can be set to install multiple device drivers. Here are the steps to create an MSI with the DIFxAPP merge module:
In the setup folder, create a separate directory in the Application Folder for the driver package and add the driver files to the folder.
Add the DIFxApp.msm to the setup project.
Build the setup
Use Orca to edit the MSI database table and add the INF component to the DIFxAPP merge modules table.
The Orca installation is included in the Windows SDK in the ‘C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin’ directory. (The Windows SDK can be downloaded from Microsoft)
Run Orca and select the MSI package that needs to be modified.
Read part 5 for automation.
In the ‘File’ table, locate the INF file of the driver package you would like to install and copy the Component value.
Create a new row in the MsiDriverPackages table. Add the Component value into Component field. The following flags can be used (although some are ignored by Windows 7):
0 - Not set (default)
1 – Force installation of driver, even if it the currently installed drivers is
a better match than the driver being installed
2 – Suppress message box telling user to plug in devices after the driver
has been installed.
4 – Suppress adding an entry in Add/Remove Programs for driver.
Driver will be uninstalled when main application is uninstalled.
8 – Install unsigned driver packages
16 – Remove driver binaries during uninstall.
Save the MSI. In order to automate the process, the editing of the MSI database can be recorded to a Transform and then the Transform can be applied in a post build process.
Open the MSI in Orca.
Select Transform->New Transform
Complete steps 3 and 4 in the above directions.
Select Tranform->Generate transform and save the transform.
Add the following line to the post build of the Setup Project
MsiDb.exe -t transform.mst -d $(TargetDir)\DriverInstall.msi
Note: MsiDB.exe comes with the Microsoft SDK and is located in
C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin
If you get an error installing from the MSI (e.g. I got error code 2356 which ended up being due to an invalid Flag value), use Orca's Validate function to see if there are any errors. EDIT: Fixing these errors still has not gotten rid of the error. I remember reading that inf files should be in their own sub-directory, but that didn't fix my problem either.
I followed the KB article from MS in order to turn on MSDTC trace. Unfortunately it was hard to follow, since it doesn't assume a very reasonable and obvious expectation of the reader, specifically "how do I read this binary log file?" I read this page from MSDN as well, where I find that I can't read the log file because I'm missing some executable called tracefmt.exe, and I'm apparently the only one anywhere with this problem.
Hence my question: Why don't I have tracefmt.exe and where do I get it? or, to get to the point: How do I read my MSDTC trace logs?
With Visual Studio 2010 installed, I found the tool in the following location:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\x64\TraceFmt.exe
I then copied the .EXE to the following location:
C:\Windows\System32\Msdtc\Trace
And ran it as follows:
TraceFmt.exe dtctrace.log.2012-06-13-10-38-57-0601-00
Although most of the time I use msdtcvtr.bat, as follows:
C:\Windows\System32\Msdtc\Trace\msdtcvtr.bat -tracelog dtctrace.log.2012-06-13-10-38-57-0601-00
To save on downloading all of the WDK (600MB+), just for 200KB of files, I opted for a 4.7MB download by doing the following:
Download "Windows XP Service Pack 2 Support Tools" from here: http://www.microsoft.com/downloads/details.aspx?FamilyId=49AE8576-9BB9-4126-9761-BA8011FABF38&displaylang=en
If running from XP, just extract and go
If running from 2003 (like I am), you'll get an error saying this can only be installed on XP. So to get around this, use a tool to extract the exe instead.
Inside the exe will be a support.cab, extract the contents of this somewhere
Look for these two files, tracefmt.exe and traceprt.dll. Copy these to your %windir%\system32\msdtc\trace directory
tracefmt (and traceview which is easier to use) are available in the Windows Driver Kit (WDK). It is available here: http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11800. It is in the WDK since this tracing technology is more commonly used in device drivers.
DTC Tracing
The Distributed Services Support Team blog goes over how to trace the DTC in more detail.
Windows Driver Kit
The links in the accepted answer seem to be broken. I've found the Windows Driver Kit homepage and current download link.
Once you have the ISO downloaded and you're at the installation screen, Microsoft Windows Driver Kit, select only Tools from Full Development Environment. The tracefmt.exe is in <install-path>\<version>\Tools\tracing\i386. Make sure you copy the version of tracefmt.exe from the 64-bit or 32-bit directory!
The blogger above moved those files to the DTC folder %systemroot%\MsDtc\Trace, probably so they were in the msdtcvtr.bat path.
After searching for tracefmt.exe and traceprt.dll from the above posts (and elsewhere) I found that you need the 64 bit version of the tools for the program to run on Windows Server 2008.
I found this blog post.
and found that if you have visual studio installed you should be able to find both the 64-bit and 32-bit versions for the exe and dll on your local machine:
ProgramFiles\Microsoft SDKs\Windows\v6.0A\Bin\ (32 bit)
ProgramFiles\Microsoft SDKs\Windows\v6.0A\Bin\x64\ (64 bit)
Tracefmt.exe comes with the Windows Driver Kit.
http://www.microsoft.com/downloads/details.aspx?FamilyID=2105564e-1a9a-4bf4-8d74-ec5b52da3d00&displaylang=en
Very often you should use existed *.mof file for enconding trace files.
In C:\Windows\System32\Msdtc\Trace\ u can see msdtctr.mof.
This file has description of the trace files and u need to use it file like this:
tracefmt log_filename -tmf msdtctr.mof
I found Darren's and Thomas Bratt's answers quite helpful, but in order to successfully parse DTC files using tracefmt, I had to provide the tmf parameter:
tracefmt -tmf msdtctr.mof dtctrace.log
Otherwise every event turned out something like
Unknown( 21): GUID=75f91e0e-d50c-47c9-b06f-3f2013e9da73 (No Format Information found).