This is a very simple FASM 64-bit driver example and it is NOT DIGITALLY
SIGNED.

After unzipping the attached file, please carefully read the "Readme.txt" file.

WARNING: The driver DOES NOT WORK on Windows 10. I already reported that
to Tomasz so that he can fix the problem.

Could you edit your post/readme to reflect exactly what the driver is supposed to do? Thank you.

Hi,

The driver just makes a "beep" when loading and another "beep" when downloading. The only purpose of this simple example is showing how to build a 64-bit driver (the basic structure). Anyway, here is the Readme.txt file:

This is a very simple FASM 64-bit driver example and it is NOT DIGITALLY
SIGNED. NON-SIGNED drivers do not work if the 64-bit Windows is started
normally.

To run a NON-SIGNED driver on any Windows 64-bit operating system, you
have to press F8 at boot. Then, in the boot menu, select the "Disable
driver signature enforcement" option.

Once you started Windows with "Disable driver signature enforcement",
double-click on the test program ("FSDrv64Test.exe").

WARNING: The driver DOES NOT WORK on Windows 10. I already reported that
to Tomasz so that he can fix the problem.

Regards.

Win 10 x64 refused to load my drivers. Removing relocs helped. Luckily they contain address independent code and use RIP-relative addressing everywhere so relocs are not necessary.

Hi Feryno,

Could you please tell me what you exactly mean? Maybe with a few lines of code. Thanks.

Regards.

delete or comment out this line in your asm file:
section '.reloc' fixups data readable discardable
That helped me at w10 x64. I also have modified version of fasm to compile drivers, which change 1 or 2 bits in PE32+ header. If removing relocs does not help you let me know, you will need to modify then something else in driver header.

Hi Feryno,

Thank you very much for your help!

No, removing "section '.reloc' fixups data readable discardable" does not solve the problem. The attached simple driver does not work in WIN10, while the same driver compiled with other assemblers (GOASM, MASM, POASM, etc.) works perfectly well. So I think the FASM assembler should be revised.

Regards.

Can you tell me why you need to used this? :

native 5.02 at 10000H

Well, I don't know exactly, I saw it in some examples and I thought it was the right way to build a 64-bit driver.

I'm new to FASM.

If you have a working driver created with some other tool, you can try to create its replica with fasm, by setting the same flags, attributes, sections names and order, etc. With fasm's built-in PE formatter you can quite well customize the structure of the PE file you produce but this also means that you need to write source that specifies all the required options, and drivers have been known to be sensitive to such tweaking.

And perhaps you may find out that there is some flag or attribute that fasm does not include as an option to set - but then you can report such problem to me and I may add some new keywords, like I did with WDM.

If you don't want or need to control everything manually, then the better option for you is to use "format MS COFF" and then use a linker of your choice to generate PE file (probably the best choice would be the linker from DDK).

Perhaps those 1 or 2 bits should become additional options for fasm's "format PE"? What are they?

Hi Tomasz,

Thanks for you reply!

I will do what you suggest and let you know the results. Just for your information, the simple driver I attached in this post only fails in the new Windows 10. It works fine on WIN7/8.

Regards!

formats.inc the above modification was necessary to compile x64 driver which was able to load
under win 10 x64 even such driver failed to load, but removing relocs section helped and then loaded OK

Feryno
Omg, relocations again. You guys aren't fans of simple solutions. Is it just more fun to modify the compiler than to use the standard means that the compiler already provides? All you need to do is this:

or this:

The latter one is even included in the fasm examples.

Hi l_inc,

Well, the driver finally WORKS PERFECTLY WELL on WIN7, WIN8 and WIN10, just by adding the code you suggested:




Thank you very much for your help. Also thank you very much everybody.

Please forgive my ignorance about this known issue and its solution.

I attach the modified version working fine on all 64-bit Windows.

Regards!

l_inc thank for different solution !

I feel interesting for this question: why WIN10 needs one dll to add one empty relocation entry in the relocation section? WIN10 maybe change this behavior in the future?

Thanks.

Kenneth Zheng

I got it to work on windows 10.
Would you please publish the source of the test program (FSDrv64Test.exe)?

The procedure to disable the driver signature enforcement:

hold shift key while pressing on restart.
On the blue screen:
click Troubleshoot,
click Advanced options,
click startup settings
click the restart button.

wait until the blue screen appears with options to choose from.

choose option 7 : Disable driver signature enforcement

Now windows startup continues.

IMHO the correct way to test drivers is to use the DSEO utility.
It not only disables driver checking by the system, but also creates a "Security" section with a test signature in the executable PE (exe, dll, sys). Developer's website:
https://www.ngohq.com/2008/04/25/driver-signature-enforcement-overrider/

The tool looks handy and easy to use.
I do it manually to force bootmgr to start in textmode instead of GUI so no need any restart to disable drvsigning, the important is the last command
you need to run cmd.exe with admin privileges (right click on in -> run as administrator), its usual location is C:\windows\system32\cmd.exe
bcdedit /set {bootmgr} displaybootmenu yes
bcdedit /set {bootmgr} timeout 5
bcdedit /set {current} bootmenupolicy legacy

on every boot the text mode starts when it is possible to press F8 and then choose 'disable driver signature enforcement'
the second command adjusts the timeout which is by default 30 seconds

another way is to boot OS into debug mode
bcdedit /set {current} debug on
bcdedit /dbgsettings serial debugport:1 baudrate:115200
for more refer here: https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/bcdedit--dbgsettings
that requires serial ports on 2 computers and connection via null modem cable (without the connection and proper setup of both machines the OS just does not initialize debug mode and you just waste few seconds during boot when OS tries to establish the connection)
for more read here:
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-null-modem-cable-connection

also a lot of LAN adapters are supported as today most of computers lack serial ports so you can establish debug connection using network cable

when you have only 1 computer, you can install virtualization solution like vmware and use a pipe for the debug connection - I really suggest you to do so if you want to develop drivers

The virtual machine method is easier, faster, requires only 1 computer but you need a virtualization software.
2 machines with a cable connection are necessary when you do hardware specific drivers.

I can help you with that. I did kernel / drivers debugging several thousands of times (virtual machine as well hardware).

Why don't you use test certificates? It's more convenient than debug mode with two nodes. For example, if you enable test mode with utility DSEO and then look at the bcdedit keys (before & after), it also sets "TESTSIGNING" (bool). Help:

bcdedit /? types bootapp
bcdedit /? types osloader