I know that this problem has been stated multiple times, but I cannot seem to find any solution. The issue is that I compiled in release mode the kmdf hello world example from Microsoft's website, but I am not able to run it. The reason is that when I try to launch the service, I get the following error: "The driver has been blocked from loading". I Obviously get this error because I have not signed the driver, but even though I have disabled signature enforcement on my updated Windows 10 machine (as stated here) I still cannot launch the driver, and I get exact the same message. So basically the option for temporarily deactivating signature enforcement, seems to serve a completely decorative purpose. So, is there any other way to launch my unsigned driver on my Windows 10 Virtual Machine, or I need to pay $100 to run my code on my own computer ?
The tutorial that you're using mentions that you need to provision your target machine for driver deployment, and leads to the "Provision a computer for driver deployment and testing" page which (among other things) has the following instructions:
On the target computer, run the WDK Test Target Setup MSI that matches
the platform of the target computer. You can find the MSI in the
Windows Driver Kit (WDK) installation directory under Remote.
Example: C:\Program Files (x86)\Windows Kits\10\Remote\x64\WDK Test
Target Setup x64-x64_en-us.msi
If you want to deploy your driver manually (for example, if you're testing your driver on your development machine or in a VM), instead of running the aforementioned MSI you can manually enable test signing mode by running bcdedit -set TESTSIGNING ON from the elevated command prompt. You would need to reboot the machine for the changes to take effect.
See "The TESTSIGNING Boot Configuration Option" on MSDN for additional details.
Related
I was trying to test this File System Minifilter Driver sample. I'm having a problem with the deployment because this is not an actual device driver (non-PnP driver).
In Visual Studio, in the property page of the project: Driver Install -> Deployment, If I select "Hardware ID Update", I don't know what is the hardware ID for the driver and I cannot see in the .INF file either.
If I select "Install/Reinstall and Verify" -> "Default Driver Package Installation Task (possible reboot)", I get Driver Deployment Task Failed: Default Driver Package Installation Task error.
Deployment settings in VS
I checked this and this page but I couldn't find anything beside how to prepare the .INF file.
How can I deploy this driver to my target machine? Thank you.
Actually you don't need an INF file to install your mini filter driver.
First, create a kernel driver service with either "sc create" from command line or call "CreateService" from your installation program if you want to automate the deployment.
Then, add some registry modification as below (from Norton 360) with Registry Editor or again with Win32 registry APIs in your installation program:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SymEFASI\Instances]
"DefaultInstance"="SymEFASI"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SymEFASI\Instances\SymEFASI]
"Flags"=dword:00000000
"Altitude"="260610"
Replace "SymEFASI" with your driver service name when running "sc create" or calling "CreateService". The most important part is "Altitude". It needs to be unique in your system, otherwise Filter Manager won't load your driver due to conflicts. For a formal product deployed in the real world to end-users, you need to apply for a unique number assigned by Microsoft. This is also critical because mini filter drivers are classified by layers. Each layer has its own functionalities. If your driver sits on the wrong layer, you might not see the correct data or behavior as you want.
Once the above is done, the last thing is to run "sc start" or call "StartService".
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.
I have an app that developed for Windows 7 & 8. Developed in VS2010 using C++/CLI. When tried to certify with Windows App Certification Kit, it shows a warning.
Binary analyzer
Warning: The binary analyzer test detected the following errors:
File C:\Program Files (x86)\MyApp\msvcr100.dll has failed the ExecutableImportsCheck check.
File C:\Program Files (x86)\MyApp\msvcp100.dll has failed the ExecutableImportsCheck check.
Impact if not fixed: If the app doesn’t use the available Windows protections, it can increase the vulnerability of the customer's computer to malware.
How to fix: Apply the SAFESEH, DYNAMICBASE, and NXCOMPAT options when you link the app.
How can I avoid this warning from my app.
It makes no sense to use WACK on your project. It was made to verify WinRT apps, the kind that are published through the Store and run on Windows 8.x or Windows Phone. They need to be safe to run in a very restricted sandbox that makes a very small subset of the winapi available. Limited for security, deployment and power-consumption reasons, what WACK verifies. A desktop DLL like msvcr100.dll cannot meet them. Such apps are built with another CRT, vccorlibxxx.dll
You cannot build such an app with VS2010, VS2012 or higher required. Nor can it run on Win7. You simply need to stop using the tool.
Update: it does appear that WACK was updated in the 8.1 SDK to also verify Windows Logo requirements for desktop apps. This is obscure. Judging from the command help that's displayed when I run appcert.exe /? in an elevated command prompt, you must first create an installer for your app. Then you can run appcert with the -apptype desktop and the -setuppath yourinstaller.exe to have it perform the validation. Some additional command line options appear to matter, like -appusage. I don't know what they mean.
Do keep in mind that this is only useful if you need the Windows Logo certification. There ought to be additional information in the logo program documentation about this. Consider contacting Microsoft if you have Windows Logo program questions.
I have a VB6 application I am trying to get working on a Windows 7 environment, however every time I start the application, I get the error:
"Component 'ComCt332.ocx' or one of its dependencies not correctly registered: a file is missing or invalid".
To resolve, I have tried to register the comct332.ocx file by running the regsvr32 in the Command Prompt in Administrator Mode but then I get the error:
"The module "comct332.ocx" was loaded but the call to DllRegisterServer failed with error code 0x80004005"
Other things I have tried include:
Deleting all parent nodes in the registry where 'comct332.ocx' exists
and running regsvr32 again in Admin Mode. Same result.
I granted admin permission to another user on the PC and I could register the
file successfully, and the application starts and runs successfully!
However when I log in as the previous user again, it fails miserably.
Any help, thoughts, other-things-to-try will be much appreicated. Thanks
If you have been keeping up on things as you must if you are to continue using VB6 successfully there are a number of things you'll be aware of.
One of these is the impact of UAC and per-user registry
virtualization.
Another is the impact of SysWOW registry redirection on 64-bit
systems.
You will understand that proper installation packages are more important than ever before. Windows has many auto-remediations for legacy software but some of them will not result in applications having all of the originally intended behaviors. Most of them will only be applied when your application "follows the right path" from installation to second run.
Here we have a case that is intended to be handled through use of a proper Windows Installer package, or at least a legacy setup recognized as such through Windows' "legacy installer detection heuristics." In general legacy scripted setups are deprecated but as long as they stay on the path Windows makes efforts to ensure they succeed.
Manually deploying by just copying over a bunch of files and randomly running regsvr32 on some of them has a reduced chance of success. This was never an approved method of deployment anyway.
You have most likely run afoul of some combination of registry virtualization and redirection.
The regsvr32 utility is a development tool, not a deployment tool. If you insist on trying to use it for deployment you must follow the same rules a developer must follow:
Run the correct version. On a 64-bit system there are both 64- and
32-bit versions of this utility. The 32-bit version which you must
use is located in the SysWOW64 folder.
Run it from an elevated command prompt. An easy
way to start one is to type <Winkey>cmd.exe<Ctrl-Shift-Enter> then
approve the UAC prompt or provide over-the-shoulder admin credentials
as needed.
There are many other things you need to know and handle in order to be successful. If you have ignored those most of them will only become apparent to you after your program gets installed and will run. A lot of them stem from filesystem virtualization.
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.