Why do I get the error, Error loading OSFMount Driver?

To create a RAM drive or mount a disk image into a RAM with a drive letter, OSFMount uses a device driver to create a virtual disk volume. This device driver is called OSFMount.sys and it is loaded the first time you create a new drive with OSFMount.

Sometimes, depending on your operating system there is a problem running this device driver and you'll get the message, Error loading OSFMount Driver. This error is usually related to code signing problems.

In V1.x of OSFMount this was not normally a problem as the device driver we were shipping was from the year 2012. That is to say it was an old driver, and exempt from some of the new signing checks. But with the release of V2.0 of OSFMount in 2018 we did a lot of work in the driver to improve performance. Being a new driver, this initially fell foul of the new Win10 build 1607 signing requirements. With the V2.0 build 1001 release of OSFMount we got our new driver signed by Microsoft. So OSFMount V2.0 build 1001 largely corrects this issue.

However if you are using Windows Server 2016, or the orginal Win7 release without any patches, there is still a problem, so read on.

Background information on code signing

Coding signing proves the software came from a particular developer and protects against corruption and manipulation of the driver code. So it helps prevent malware and viruses.

Over the years Microsoft has changed the signing requirements for loading kernel mode device drivers.

• In Windows XP there was no special requirements.
• In Windows Vista 32bit only boot start drivers needed to be code signed
• In Windows Vista 64bit all drivers needed to be code signed
• In Windows 7 64bit SP0 all drivers needed to be signed using the SHA1 hash. SHA256 hashes will not work.
• In Windows 7 SP1 64bit, fully patched, all drivers needed to be signed using either the SHA1 hash or the SHA256 hash
• In Windows 8 all drivers needed to be signed using either the SHA1 hash or the SHA256 hash
• In Windows 10 initial release all drivers needed to be signed using either the SHA1 hash or the SHA256 hash
• In Windows 10 build 1607 all drivers needed to be EV signed (extended validation) using either the SHA1 hash or the SHA256 hash. Further new Win10 installs will not load new drivers unless that have been submitted and passes Microsoft Hardware Dev Center requirements and be signed a 2nd time. If you did an upgrade from Win7 to Win10, then (bizarrely) the rules are different. If you aren't using secure boot, then the rules are different. If you are using a driver from before 29th July 2015, then the rules are different.
• In future windows releases Micorosft, 2020 onwards, will be starting to remove support for SHA1. So only SHA256 will work at some future point.
• As a software developer there are two methods of getting a driver signed with Microsoft’s certificate. Attestation signing & HLK Test and submission. Both are expensive, stupidly complex and time consuming. Attestation signing is the easier of the two, but the result is that you only get a device driver that will work with Win10. The driver that previously worked in Win7 breaks after being signed by Microsoft! No verions of Windows Server are supported either! If you want 64bit and 32bit then multiple submissions are required. Getting the mandatory .INF correct is also a major problem as the error reporting and technical support from Microsoft is non existant. The 2nd HLK method is insanely time consuming and typically invovles setting up around a ten different test machines per driver release if broad compatibility is required.

A more complete description of the Win10 1607 signing changes can be found here

From OSFMount V2.0 we are signing the driver with a Extended Validation (EV) SHA256 certificate. This means it won't work in a unpatched release of Win7. It also won't work (yet) in Win10 releases that new and are using secure boot.

Patching Win7 for SHA256 signing

If you turn on automatic patches then Windows 7 should update itself to support SHA256 code signing and this will fix the problem.

You could alternatively download and run these two hot fixes manually

KB3033929

Information: https://support.microsoft.com/en-us/kb/3033929

KB2921916

Information: https://support.microsoft.com/en-us/kb/2921916

Windows Server 2016 installs with secure boot

OSFMount and Windows Server 2016 have a problem. OSFMount itself should work fine in Windows Server, but the signing is a problem. Even after getting the driver signed by Microsoft, they still don't let it run on Windows Server. There are methods however to turn off driver verification on Windows Server 2016. You copuld also turn off secure boot in BIOS