I have a simple 32-bit legacy kernel driver. It performs simple I/O port R/W?s and already works on XP, 32-bit W7 etc where I use service manager calls to install and run it. My user ?mode program that calls it is 32-bit (Delphi).
I now wish to see it work on 64-bit Windows 7 before I do any more work on it, i.e to get myself over the sign / test loop. I have had troubles using test signing on my driver so today I decided that I would follow a procedure using a DDK sample to check I understood the procedure. I?ve failed and perhaps someone could cast their eye over my stumbling procedure please? I apologise in advance for the verbose nature of this and thank you the reader for taking the time to carry on!
Brian.
Using Windows 7 64-bit with W7 DDK (7600.16385.0)
Windows has been placed into test mode (showing at bottom right)
I took a copy of the DDK sample ?portio? from ?C:\WinDDK\7600.16385.0\src\general\portio? into my working folder ?c:\driver?
Navigating to ?C:\driver\portio\sys? I used the ?x86 Checked Build Environment? to perform a build. The result is ?genport.sys? (presumably a ?simple? 32-bit object due to use of ?XP??)
For simplicity, I copy ?genport.sys? into ?c:\driver\genport.sys? before trying to load it.
I performed:
sc create type= kernel binpath= “c:\driver\genport.sys” start= auto
with ?Success?.
?sc query genport? returns stopped, exit code 1077 and ?sc start genport? returns ?[SC] StartService FAILED 1275 This driver has been blocked from loading?
I thought this might be a sign issue, so I did ?sc delete genport? and then tried a signing process:
Step1: C:\WinDDK\7600.16385.0\bin\x86\makecert.exe -$ individual -r -pe -ss “SelfSigning Store” -n CN=“BJF” “BJF.cer”
Result was success.
Result:
The following certificate was selected:
Issued to: BJF
Issued by: BJF
Expires: Sat Dec 31 23:59:59 2039
SHA1 hash: 38BD2F18765E6D36E97F70734B3F0178D7BCAA57
Done Adding Additional Store
Successfully signed: c:\driver\genport.sys
Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0
Now I try to install the driver with:
sc create genport type= kernel binpath= “c:\driver\genport.sys” start= auto
(success)
Query it with “sc query genport” Returns:
SERVICE_NAME: genport
TYPE : 1 KERNEL_DRIVER
STATE : 1 STOPPED
WIN32_EXIT_CODE : 1077 (0x435)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
15.Try to start it with ?sc start genport? returns: [SC] StartService FAILED 1275:
This driver has been blocked from loading
Finally, I tried the utility ?Driver Signature Enforcement Overrider? (dseo13b.exe) and nominated ?c:\driver\genport.sys? to sign which it told me had been done ok. Repeating SC CREATE etc as above gave exactly the same ?blocked? result.
Are you trying to load a 32-bit driver on 64-bit Windows?
If so, this will not work.
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@appliedrelaytesting.co.uk
Sent: Tuesday, February 01, 2011 7:07 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Newbie trying to understand the Windows 64 sign
requirements for a 32-bit driver
I have a simple 32-bit legacy kernel driver. It performs simple I/O port
R/W?s and already works on XP, 32-bit W7 etc where I use service manager
calls to install and run it. My user ?mode program that calls it is 32-bit
(Delphi).
I now wish to see it work on 64-bit Windows 7 before I do any more work on
it, i.e to get myself over the sign / test loop. I have had troubles using
test signing on my driver so today I decided that I would follow a procedure
using a DDK sample to check I understood the procedure. I?ve failed and
perhaps someone could cast their eye over my stumbling procedure please? I
apologise in advance for the verbose nature of this and thank you the reader
for taking the time to carry on!
Brian.
Using Windows 7 64-bit with W7 DDK (7600.16385.0)
Windows has been placed into test mode (showing at bottom right)
I took a copy of the DDK sample ?portio? from
?C:\WinDDK\7600.16385.0\src\general\portio? into my working folder
?c:\driver?
Navigating to ?C:\driver\portio\sys? I used the ?x86 Checked Build
Environment? to perform a build. The result is ?genport.sys? (presumably a
?simple? 32-bit object due to use of ?XP??)
For simplicity, I copy ?genport.sys? into ?c:\driver\genport.sys? before
trying to load it.
I performed:
sc create type= kernel binpath= “c:\driver\genport.sys” start= auto
with ?Success?.
?sc query genport? returns stopped, exit code 1077 and ?sc start genport?
returns ?[SC] StartService FAILED 1275 This driver has been blocked from
loading?
I thought this might be a sign issue, so I did ?sc delete genport? and
then tried a signing process:
Step1: C:\WinDDK\7600.16385.0\bin\x86\makecert.exe -$ individual -r -pe
-ss “SelfSigning Store” -n CN=“BJF” “BJF.cer”
Result was success.
Result:
The following certificate was selected:
Issued to: BJF
Issued by: BJF
Expires: Sat Dec 31 23:59:59 2039
SHA1 hash: 38BD2F18765E6D36E97F70734B3F0178D7BCAA57
Done Adding Additional Store
Successfully signed: c:\driver\genport.sys
Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0
Now I try to install the driver with:
sc create genport type= kernel binpath= “c:\driver\genport.sys” start= auto
(success)
Query it with “sc query genport” Returns:
SERVICE_NAME: genport
TYPE : 1 KERNEL_DRIVER
STATE : 1 STOPPED
WIN32_EXIT_CODE : 1077 (0x435)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
15.Try to start it with ?sc start genport? returns: [SC] StartService FAILED
1275:
This driver has been blocked from loading
Finally, I tried the utility ?Driver Signature Enforcement Overrider?
(dseo13b.exe) and nominated ?c:\driver\genport.sys? to sign which it told me
had been done ok. Repeating SC CREATE etc as above gave exactly the same
?blocked? result.
> I have a simple 32-bit legacy kernel driver. It performs simple I/O port R/W?s and already works on XP, 32-bit W7 etc where I use service manager calls to install and run it. My user ?mode program that calls it is 32-bit (Delphi). > > I now wish to see it work on 64-bit Windows 7 before I do any more work on it, i.e to get myself over the sign / test loop. I have had troubles using test signing on my driver so today I decided that I would follow a procedure using a DDK sample to check I understood the procedure. I?ve failed and perhaps someone could cast their eye over my stumbling procedure please? I apologise in advance for the verbose nature of this and thank you the reader for taking the time to carry on! > Brian. > > 1. Using Windows 7 64-bit with W7 DDK (7600.16385.0) > 2. Windows has been placed into test mode (showing at bottom right) > 3. I took a copy of the DDK sample ?portio? from ?C:\WinDDK\7600.16385.0\src\general\portio? into my working folder ?c:\driver? > 4. Navigating to ?C:\driver\portio\sys? I used the ?x86 Checked Build Environment? to perform a build. The result is ?genport.sys? (presumably a ?simple? 32-bit object due to use of ?XP??) > 5. For simplicity, I copy ?genport.sys? into ?c:\driver\genport.sys? before trying to load it. > 6. I performed: > sc create type= kernel binpath= “c:\driver\genport.sys” start= auto > with ?Success?. > 7. ?sc query genport? returns stopped, exit code 1077 and ?sc start genport? returns ?[SC] StartService FAILED 1275 This driver has been blocked from loading? > 8. I thought this might be a sign issue, so I did ?sc delete genport? and then tried a signing process: > 9. Step1: C:\WinDDK\7600.16385.0\bin\x86\makecert.exe -$ individual -r -pe -ss “SelfSigning Store” -n CN=“BJF” “BJF.cer” > Result was success. > 10. Step 2: C:\WinDDK\7600.16385.0\bin\x86\CertMgr.Exe /add “BJF.cer” /s /r localMachine root > 11. Result ?CertMgr succeeded?. > > 12. Step 3: C:\WinDDK\7600.16385.0\bin\x86\signtool.exe sign /v /s “SelfSigning Store” /n “BJF” “c:\driver\genport.sys” > > Result: > The following certificate was selected: > Issued to: BJF > Issued by: BJF > Expires: Sat Dec 31 23:59:59 2039 > SHA1 hash: 38BD2F18765E6D36E97F70734B3F0178D7BCAA57 > > Done Adding Additional Store > Successfully signed: c:\driver\genport.sys > > Number of files successfully Signed: 1 > Number of warnings: 0 > Number of errors: 0 > > 13. Now I try to install the driver with: > sc create genport type= kernel binpath= “c:\driver\genport.sys” start= auto > (success) > 14. Query it with “sc query genport” Returns: > SERVICE_NAME: genport > TYPE : 1 KERNEL_DRIVER > STATE : 1 STOPPED > WIN32_EXIT_CODE : 1077 (0x435) > SERVICE_EXIT_CODE : 0 (0x0) > CHECKPOINT : 0x0 > WAIT_HINT : 0x0 > 15.Try to start it with ?sc start genport? returns: [SC] StartService FAILED 1275: > This driver has been blocked from loading > 16. Finally, I tried the utility ?Driver Signature Enforcement Overrider? (dseo13b.exe) and nominated ?c:\driver\genport.sys? to sign which it told me had been done ok. Repeating SC CREATE etc as above gave exactly the same ?blocked? result. > > Any help appreciated. > Thanks
You can always disable signature check in x64 Windows by pressing F8 and choosing “Disable signature check”.
However, before you reach that stage, make sure your driver works in x64 - you will have to make a full range of tests - starting from manual debugging to prefasting, profiling, driver verifying, etc.
Thanks Don and ‘mm’ for your comments. I’m still a bit confused. If I create a 64-bit driver (by choosing a 64-bit build environment?) can my (32-bit) Delphi program still talk to it in the same way?
Regards, Brian.
Right. On a system running 64-bit Windows, all the kernel-mode code has to be 64-bit. The OS takes care of allowing your 32-bit programs to run, and the driver should work seamlessly. Just build it in the 64-bit Build Environment.
Note you can load the driver on 64-bit Windows with the debugger attached, so try that first to ensure you’ve got things working.
The only potential problems you’ll have is if your driver has IOCTLs that pass data structures (not just user data buffers) to/from the driver. There are SOME cases where the driver will actually need to be modified to be aware of whether it’s talking to a 32-bit or a 64-bit application (for example, consider that if one of the things in the IOCTL data buffer was a pointer to something… the driver would need to know whether that pointer was 32-bits long or 64-bits long, and this would depend on whether the IOCTL was coming from a 32-bit or a 64-bit application).
Any field that is bitness-sensitive can cause problems when using 32-bit
application on 64-bit platform.
In addition to pointers, “int” and “enum” (which is int under the hood)
fields will cause a problem.
Thomas F. Divine
From: Sent: Tuesday, February 01, 2011 9:32 AM To: “Windows System Software Devs Interest List” Subject: RE:[ntdev] Newbie trying to understand the Windows 64 sign requirements for a 32-bit driver
> Right. On a system running 64-bit Windows, all the kernel-mode code has > to be 64-bit. The OS takes care of allowing your 32-bit programs to run, > and the driver should work seamlessly. Just build it in the 64-bit Build > Environment. > > Note you can load the driver on 64-bit Windows with the debugger attached, > so try that first to ensure you’ve got things working. > > The only potential problems you’ll have is if your driver has IOCTLs that > pass data structures (not just user data buffers) to/from the driver. > There are SOME cases where the driver will actually need to be modified to > be aware of whether it’s talking to a 32-bit or a 64-bit application (for > example, consider that if one of the things in the IOCTL data buffer was a > pointer to something… the driver would need to know whether that pointer > was 32-bits long or 64-bits long, and this would depend on whether the > IOCTL was coming from a 32-bit or a 64-bit application). > > Peter > OSR > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer
Thanks Peter, it all helps clarify things. I’m sending and receiving via a
simple buffer and using DWORDs to hold simple values so presumably these
will transfer across between my 32-bit prog and the 64-bit driver ok?
Brian.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: 01 February 2011 14:32
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Newbie trying to understand the Windows 64 sign
requirements for a 32-bit driver
Right. On a system running 64-bit Windows, all the kernel-mode code has to
be 64-bit. The OS takes care of allowing your 32-bit programs to run, and
the driver should work seamlessly. Just build it in the 64-bit Build
Environment.
Note you can load the driver on 64-bit Windows with the debugger attached,
so try that first to ensure you’ve got things working.
The only potential problems you’ll have is if your driver has IOCTLs that
pass data structures (not just user data buffers) to/from the driver. There
are SOME cases where the driver will actually need to be modified to be
aware of whether it’s talking to a 32-bit or a 64-bit application (for
example, consider that if one of the things in the IOCTL data buffer was a
pointer to something… the driver would need to know whether that pointer
was 32-bits long or 64-bits long, and this would depend on whether the IOCTL
was coming from a 32-bit or a 64-bit application).
I am glad to have Doron confirm that. It may well be documented somewhere
in the MSVC tomb somewhere.
Like Thomas, however, I have been rather conservative in that regard
defining IOCTL structures passing the 32/64 boundary that carry the value of
an enum to be INT32 to be darn sure.
But now I can declare them as the enum type and happily see the symbolic
value in the debugger.
SIZE_T and size_t, ptrdiff_t, etc, however, another story.
Cheers,
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@pcausa.com
Sent: Tuesday, February 01, 2011 10:59 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Newbie trying to understand the Windows 64 sign
requirements for a 32-bit driver
All: I have been eating too many stupid pills lately.
Sorry for the bogus note about int and enum causing problems.
( Could have sworn I just fixed something related to that, but not so…)
What about packing? Are there default alignment differences?
On Tue, 1 Feb 2011 09:32:04 -0500 (EST), xxxxx@osr.com wrote:
Right. On a system running 64-bit Windows, all the kernel-mode code has to be 64-bit. The OS takes care of allowing your 32-bit programs to run, and the driver should work seamlessly. Just build it in the 64-bit Build Environment.
Note you can load the driver on 64-bit Windows with the debugger attached, so try that first to ensure you’ve got things working.
The only potential problems you’ll have is if your driver has IOCTLs that pass data structures (not just user data buffers) to/from the driver. There are SOME cases where the driver will actually need to be modified to be aware of whether it’s talking to a 32-bit or a 64-bit application (for example, consider that if one of the things in the IOCTL data buffer was a pointer to something… the driver would need to know whether that pointer was 32-bits long or 64-bits long, and this would depend on whether the IOCTL was coming from a 32-bit or a 64-bit application).
Well, pointers are aligned on natural boundaries… But, 32-bit clients are built with 32-bit definitions and use 32-bit pointers (embedded in structures). 64-bit clients are built with 64-bit definitions and use 64-bit pointers (embedded in structures).
There used to be an article on 32 bit awareness in 64 bit driver on
Microsoft WHDC, seems they’ve moved it in to the online documentation
and made it harder to read by “chapterising” it. However, you can
find the start of it here http://msdn.microsoft.com/en-us/library/ff563897(v=VS.85).aspx
At 23:39 02/02/2011, Michael Wade wrote:
What about packing? Are there default alignment differences?
On Tue, 1 Feb 2011 09:32:04 -0500 (EST), xxxxx@osr.com wrote:
>Right. On a system running 64-bit Windows, all the kernel-mode
code has to be 64-bit. The OS takes care of allowing your 32-bit
programs to run, and the driver should work seamlessly. Just build
it in the 64-bit Build Environment.
>
>Note you can load the driver on 64-bit Windows with the debugger
attached, so try that first to ensure you’ve got things working.
>
>The only potential problems you’ll have is if your driver has
IOCTLs that pass data structures (not just user data buffers)
to/from the driver. There are SOME cases where the driver will
actually need to be modified to be aware of whether it’s talking to
a 32-bit or a 64-bit application (for example, consider that if one
of the things in the IOCTL data buffer was a pointer to
something… the driver would need to know whether that pointer was
32-bits long or 64-bits long, and this would depend on whether the
IOCTL was coming from a 32-bit or a 64-bit application).
>
>Peter
>OSR
Well, pointers are aligned on natural boundaries… But, 32-bit
clients are
built with 32-bit definitions and use 32-bit pointers (embedded in
structures). 64-bit clients are built with 64-bit definitions and use
64-bit
pointers (embedded in structures).
Soooooo… like I said:
[quote]
The only potential problems you’ll have is if your driver has IOCTLs
that pass
data structures (not just user data buffers) to/from the driver.
There are
SOME
cases where the driver will actually need to be modified to be aware
of
whether
it’s talking to a 32-bit or a 64-bit application.
[/quote]
There’s a paper on OSR Online about this, IIRC…
Would you describe passing a pointer in a data structure to an IOCTL
call as anything even remotely close to best practice? I curious as to
situations where this could ever come up…
There’s a fairly lengthy section in the WDK docs about dealing with alignment issues spawning from use of METHOD_NEITHER and passing pointers in structures. Someone at the top of the device stack must have a need to do this.
