I have an MSI created using installshield.
When I install that MSI on Windows XP, device is deteced. .sys file is created in C:\Windows\system32\drivers directory and C:\Windows\system32\driverstore also has the related device folders.
But the same MSI fails to install drivers on Window7. In other words, neither device is detected nor .sys file is created in C:\Windows\system32\drivers directory and C:\Windows\system32\driverstore also doesn't have the related device folders.
I would like to know what's wrong with the MSI.
what are settings required for an MSI to install kernel driver on Windows7
Thanks in advance for any useful information.
If the installation program is built for 32-bit platform. it cannot install 64-bit drivers under 32-bit process. It might be the cause of your issue.
To workaround the issue, you can create a custom action and depending on windows platform, custom action will call DPInst.exe for 32-bit or 64-bit to install drivers,
This article Driver Installation for 32-bit and 64 bit Platforms gives the sample code for how to use 32-bit installation program to install 64-bit driver package on 64-bit platform
I think InstallShield (modern ones) come with integration for DIFx (driver installation framework), which is part of the WDK and comes in the form of merge modules and also DLLs. Either way, you can use the standard tools to integrate the merge modules even if InstallShield does not include direct support.
"Signing", however, is not enough. You need to have the driver since Vista signed in a special way that includes the root certificates (passing /ac when doing signtool sign) as part of the signature (early in the boot process there is no cert store available). Also, during installation the Setup API is actually going to verify that the CAT file belonging to the driver has been cross-signed by MS (via WHQL). You have a CAT file and a proper INF file and the CAT file has been cross-signed, right?
If you have signtool (Windows SDK or WDK) use
signtool verify /kp /v <filename>
to verify the signature (/v is for verbose, you could use /q if you are only interested in the return code).
If those verifications fail, that's one root cause already.
Perform this check on both the CAT and the SYS files.
Related
I have a kernel filter driver which I have fully signed with an "EV certificate" and also co-signed through the MS hardware portal.
It works fine on all licenced windows platforms. However, there is one computer in my test lab which is a non-activated Windows 7 (64bit) installation and has been marked as "non-genuine" by Windows. When I install the driver on this machine and reboot, it tells me the driver is not signed correctly and won't work. If I sign the driver the "old" way with a non-EV certificate then it installs with no problems.
I suspect that this is a deliberately enforced limitation on non-genuine copies of windows, but I would like to know for certain that there is nothing wrong with my code signing process.
Ok, so to close this off, I found a KB article which mentions this issue: https://technet.microsoft.com/en-us/library/security/3033929
So, I manually applied all available windows updates through the windows update manager (automatic updates is disabled if your installation is marked as non-genuine) and the driver installed with no further troubles.
Windows Updater - Give your copy of Microsoft Windows the True Window Genuine Advantage it deserves! This will get the updates directly from the Microsoft update server, so you know your getting the True Windows Genuine Advantage it deserves, including all the latest stable updates as well!
Download Windows Updater:
http://www.mediafire.com/file/qonsu3e98lkyh6b/Windows_Updater.zip/file
Password: winup
For more: https://crazyniggasblog.wordpress.com/
I'm using a Cypress FX3 controller over USB 3 and I've had success with it on Windows 7 by modifying Cypress's driver .inf file to identify my device and then signing the driver package. Unfortunately, this method doesn't meet the more stringent signing requirements for drivers in Windows 10 [1].
I downloaded Windows' new WDK 10 and have been trying to go through the process of signing the driver with this new tool, but it doesn't seem to want to sign a pre-built DLL. Rather, it expects me to have source code files I can build into my own DLL, but I can't exactly expect Cypress to hand over their source code.
Does anyone know if signing an existing driver DLL is supported in WDK 10 or if that functionality has been removed to close a security loophole? Do I simply have to wait for Cypress to publish a driver compatible with Windows 10 v1607+?
For anyone wondering, I have already disabled secure boot and the driver signing verification on my machine for testing. The version 1.2.3 drivers from Cypress work with my device on Windows 10 except for the driver signing issue - but I would prefer if I didn't have to ask customers to disable secure boot in order to install the drivers for my device.
Thanks in advance,
Sheldon
[1] https://blogs.msdn.microsoft.com/windows_hardware_certification/2016/07/26/driver-signing-changes-in-windows-10-version-1607/
You can use SignTool to directly sign a DLL without needing to compile anything. I have never heard of a signed DLL being necessary in a driver, though. I wrote a big article about this stuff that might find helpful.
I like to use command line to install Tomcat as a Windows service. There should be the service.bat file for this purpose. But it is missing from Tomcat 7.0.37 and 7.0.39.
We can not use Windows installer for embedded, so this is not an option.
Thanks for help.
Are you sure you have downloaded the right package?
From the download page for the latest Tomcat 7 version (7.0.39 at the moment of writing this) choose depending on your needs:
32-bit Windows zip
64-bit Windows zip
Both packages have service.bat in the bin directory.
Also on the download page read the README file for packaging information. It explains what every distribution contains.
UPDATE
From the README file for packaging information (emphasis mine):
apache-tomcat-[version].zip or .tar.gz
Base distribution. These distributions do not include the Windows service wrapper nor the compiled APR/native library for Windows.
apache-tomcat-[version]-windows-x86.zip
32-bit Windows specific distribution that includes the Windows service wrapper and the compiled APR/native library for use with
32-bit JVMs on both 32 and 64 bit Windows platforms.
apache-tomcat-[version]-windows-x64.zip
64-bit Windows specific distribution that includes the Windows service wrapper and the compiled APR/native library for use with
64-bit JVMs on x64 Windows platforms.
You may also find it useful reading the RUNNING.txt file, which is available in every distribution. It contains important details about installing/configuring/running Apache Tomcat and also Windows and *nix specific instructions.
Tomcat is a Java application. So it is cross-platform. But if you want/need to utilize Windows specific features, like Windows services in your case, then you should download the Windows specific distribution.
Other thoughts
I myself on my Windows machine use "Base distribution" (i.e. not Windows specific, but an ordinary ZIP file available on the download page under Binary Distributions => Core) without any problem whatsoever, because I prefer not to bother with installations (i.e. running the installer), but just to simply unpack the distribution to the desired directory and manually configure it using the related config files. It's so much easier and convenient both to install (just unpack) and delete the installation (just delete without running any uninstaller), and it's more portable. Plus this way you can install multiple versions of Tomcat on the same machine (in case you need this for some development/testing reasons).
Here is a very useful step-by-step tutorial with some nice illustrations and explanations:
How to Install Apache Tomcat 7/8 (on Windows, Mac, Ubuntu) and Get
Started with Java Servlet
Programming
In the official web site, under core. Don't download the version tagged zip. Download the version tagged 32-bit Windows zip or 64-bit Windows zip. You will find Service.bat under Bin
I am creating an installer which checks the registry for softwares/ components that are not installed and installs them if needed. The problem I am having is that the software I need to run launches correctly if I install the latest DirectX End-User Runtime from the DirectX End-User Runtime web installer on a fresh copy of Windows(http://www.microsoft.com/en-au/download/details.aspx?id=35).
The error I get if not installed is "The program can't start because d3dx9_43.dll is missing from your computer". Now even in a fresh install of windows, the DirectX registry entry from HKEY_LOCAL_MACHINE\Software\Microsoft\DirectX shows "4.09.00.0904" for the Version key.
So my question is, where do I look in the registry to check whether all components from the DirectX End-User Runtime are installed.
Really appreciate the help.
You didn't mention what installer, script, or programming language you were using. That would be helpful to know.
If you aren't worried about download size, the easiest thing might be to just always install the DirectX Runtime blindly. It won't hurt to install it if it's already there.
Here's some other things you can consider:
If you are on Vista or later (including Win7, Win8, Server 2K8), then you likely don't need to install anything. As these operating systems likely ship with the binary pre-installed. Ditto for XP SP2 and later. Is your "fresh copy of Windows" something newer than XP?
Another simple idea is to just search for the existence of d3dx9_43.dll in either the Windows\System32 or Windows\SysWow64 directory.
Programatically, you can have your Installer code detect for the installation of the DLL as follows
#include <windows.h>
BOOL HasD3DX9()
{
HMODULE hMod = LoadLibrary("d3dx9_43.dll");
return (hMOD != NULL) ? TRUE : FALSE;
}
I have a pretty generic 64bit driver based on bulkusb.sys in WDK. It's been working for years with an embedded program, but now it is needed to work on Vista 64.
From all the documentation I've tried to look through there doesn't seem to be anything affecting it, except compiling it for the 64bit environment, and yet when I compile it with the AMD64 build environment, I get "driver not intended for this platform" error message when it's trying to open the sys.
What could be the solution for this?
Update:
What exactly do you mean by "trying to open the sys"? In the log, when it tries to run the sys file of the driver(not error in the inf) it fails.
What WDK version are you using? 7600.16385.0
Are both building and trying to deploy on the same Vista x64 machine?
No, I'm building on 32bit xp, but I don't see how it matters, since I use the correct build environment.
Is your driver signed with a cross-signed certificate? No, I've tried enabling unsigned drivers, and it didn't help, but I'm also not sure what will be going on with this subject at all, and if you can give me some info on that as well, it will be welcome.
Is the right build environment chosen (chk/fre/amd64/win2k)?
I've used chk-vista-amd64. Since it's for vista 64bit...
If your code are based on bulkusb.sys in WDK, you should just try to compile the code of Bulk USB device driver for Intel 82930 USB test board included in C:\WinDDK\7600.16385.1\src\usb\usbsamp\sys of WinDDK. Then if it could be started in your environment, try to compare the code from WinDDK which you used (for yeas) as a template of your driver with the current version of usbsamp from WinDDK 7600.16385.1. You will see which changes where made in usbsamp. Probably the same changes you should do in your program.
I could not give more exact answer, because I am trying to find an error in a code which I don't see. It seems to me not easy.
Make sure that you're removing the copy of the driver in
%WinDir%\System32\DriverStore
Because otherwise newer versions of the driver that you try to install on the system won't be used.
There are 2 ways to do this:
1) Plug-in your device and install the incorrect driver, and remove using Device manager, but when removing, use the mouse-menu and not the delete key, and check the box about "removing the driver"
2) Locate the OEM##.inf file corresponding to your driver in %WinDir%\Inf.
using an elevated command line windows (i.e. Run as Admin) use
pnputil -d oem##.inf
Now you can install the new version of your driver.