Kernel driver

Is there a way to reboot or shutdown Windows from a driver? I currently send a message on a port to a user application (actually a service) listening to shutdown/reboot. But, sometimes the user application hangs or has shutdown and it would be easier to just have the driver do the reboot.

Thanks,
Tim

(seq: 41E9309E-AFBD-A767-386E1B1FF836D21D)

FYI: This thread has been locked. No further replies to this topic will be allowed.

(seq: 41E94177-E03F-88E8-F4410C42B4A90DC3)

FYI: The List Slaves have re-opened this thread. You may once again post replies to this topic.

SORRY! I clicked the wrong button. I didn’t mean to lock this thread (it is now UNlocked).

There is no documented way to do this. NtShutdownSytem does… some stuff. But the overall shutdown process inherently starts in User Mode in Windows.

Peter
OSR
@OSRDrivers

Well I would say that it is better to just fix that hang you have in your
service.
Apart from NtStudownSystem there is also I believe a bugcheck that actually
cleanly shutsdown the system but I cannot recall which bugcheck this
actually is.

Regards,
Gabriel

On Fri, Mar 4, 2016 at 2:28 PM, Tim Kelly
wrote:

> Is there a way to reboot or shutdown Windows from a driver? I currently
> send a message on a port to a user application (actually a service)
> listening to shutdown/reboot. But, sometimes the user application hangs or
> has shutdown and it would be easier to just have the driver do the reboot.
>
>
>
> Thanks,
>
> Tim
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>


Bercea. G.</http:>

Thank Peter,
That’s what I thought but I wanted to make sure.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, March 04, 2016 8:57 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Kernel driver

SORRY! I clicked the wrong button. I didn’t mean to lock this thread (it is now UNlocked).

There is no documented way to do this. NtShutdownSytem does… some stuff. But the overall shutdown process inherently starts in User Mode in Windows.

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>

The hang is really when we’re tearing down and rebuilding during updates or reinstall. It’s easier or would be easier to just have the driver reboot. But, just wanted to make sure I wasn’t missing something.

Thanks

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gabriel Bercea
Sent: Friday, March 04, 2016 9:01 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Kernel driver

Well I would say that it is better to just fix that hang you have in your service.
Apart from NtStudownSystem there is also I believe a bugcheck that actually cleanly shutsdown the system but I cannot recall which bugcheck this actually is.
Regards,
Gabriel

On Fri, Mar 4, 2016 at 2:28 PM, Tim Kelly > wrote:
Is there a way to reboot or shutdown Windows from a driver? I currently send a message on a port to a user application (actually a service) listening to shutdown/reboot. But, sometimes the user application hangs or has shutdown and it would be easier to just have the driver do the reboot.

Thanks,
Tim


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:


Bercea. G.
— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:>

Concerning your actual question, KeBugCheckEx() can do the job you are asking about, but, in practical terms, it would be better to reboot from the helper userland app/service. For example, consider what happens if there are some outstanding cache flushes left at the time you call KeBugCheckEx() - although FS metadata per se will not be affected, the same does not necessarily apply to the integrity of user data…

Anton Bassov

>NtShutdownSytem does()

I thought this function was exported only via SSDT and not via IAT, i.e, this native API function was NTDLL’s export that was meant to be called only by the userland, rather than NTOSKRNL’s one available to drivers. Am I wrong?

Anton Bassov

Beats the hell out of me.

Being “not document” means its not meant to be called by drivers in any case. And NtShutdownSystem isn’t the whole answer to the problem in any case (hence my comment that it “does… some stuff”).

I’m not sure what that means, but it sounds very scary and ominous.

The file system, and its associated user data, will be consistent as of the points of the last flush. It might not be UP TO DATE. But it will be consistent. Thus guarantees NTFS. Perhaps that’s what you meant…

Peter
OSR
@OSRDrivers

Probably unhelpful to your actual problem, a simple bug check (as simple as a deliberate NULL pointer deref) will do your job very nicely

Probably you should spend some time looking at service failure actions in MSDN. I?m not sure what all your service might be doing, but writing a reboot watchdog service is a very straightforward thing to do and if the problem is that it does other stuff too consider moving that other stuff to another service. Also re your statement ?send a message on a port? I recommend that you change this design to have your watchdog service poll the status from your driver via a custom IOCTL. I don?t know what ?send a message on a port? means, but I suspect that you will have better results if the UM application does not expect to be event driven but simply had a thread that polls for status and acts on status

Sent from Mailhttps: for Windows 10

From: Tim Kellymailto:xxxxx
Sent: March 4, 2016 8:13 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] Kernel driver

Is there a way to reboot or shutdown Windows from a driver? I currently send a message on a port to a user application (actually a service) listening to shutdown/reboot. But, sometimes the user application hangs or has shutdown and it would be easier to just have the driver do the reboot.

Thanks,
Tim


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></mailto:xxxxx></mailto:xxxxx></https:>

A NULL pointer deref is not guaranteed to bugcheck (it can be handled with try/except). MM_BAD_POINTER will always bugcheck, but it’s mostly intended to catch accidental references. If you want to generate a bugcheck explicitly, call KeBugCheckEx.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Marion Bond
Sent: Friday, March 4, 2016 3:10 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Kernel driver

Probably unhelpful to your actual problem, a simple bug check (as simple as a deliberate NULL pointer deref) will do your job very nicely

Probably you should spend some time looking at service failure actions in MSDN. I’m not sure what all your service might be doing, but writing a reboot watchdog service is a very straightforward thing to do and if the problem is that it does other stuff too consider moving that other stuff to another service. Also re your statement ‘send a message on a port’ I recommend that you change this design to have your watchdog service poll the status from your driver via a custom IOCTL. I don’t know what ‘send a message on a port’ means, but I suspect that you will have better results if the UM application does not expect to be event driven but simply had a thread that polls for status and acts on status

Sent from Mailhttps: for Windows 10

From: Tim Kellymailto:xxxxx
Sent: March 4, 2016 8:13 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] Kernel driver

Is there a way to reboot or shutdown Windows from a driver? I currently send a message on a port to a user application (actually a service) listening to shutdown/reboot. But, sometimes the user application hangs or has shutdown and it would be easier to just have the driver do the reboot.

Thanks,
Tim


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></http:></http:></http:></mailto:xxxxx></mailto:xxxxx></https:>

Presumably if you want to crash the system you will not handle the exception.

And yes a deliberate call to KeBugCheck is probably a better way, but the same conclusion applies ? don?t do this as it is really not necessary given the other OS facilities available in UM

Sent from Mailhttps: for Windows 10

From: Pavel Lebedinskymailto:xxxxx
Sent: March 4, 2016 7:13 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE: [ntdev] Kernel driver

A NULL pointer deref is not guaranteed to bugcheck (it can be handled with try/except). MM_BAD_POINTER will always bugcheck, but it?s mostly intended to catch accidental references. If you want to generate a bugcheck explicitly, call KeBugCheckEx.

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Marion Bond
Sent: Friday, March 4, 2016 3:10 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Kernel driver

Probably unhelpful to your actual problem, a simple bug check (as simple as a deliberate NULL pointer deref) will do your job very nicely

Probably you should spend some time looking at service failure actions in MSDN. I?m not sure what all your service might be doing, but writing a reboot watchdog service is a very straightforward thing to do and if the problem is that it does other stuff too consider moving that other stuff to another service. Also re your statement ?send a message on a port? I recommend that you change this design to have your watchdog service poll the status from your driver via a custom IOCTL. I don?t know what ?send a message on a port? means, but I suspect that you will have better results if the UM application does not expect to be event driven but simply had a thread that polls for status and acts on status

Sent from Mailhttps: for Windows 10

From: Tim Kellymailto:xxxxx
Sent: March 4, 2016 8:13 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] Kernel driver

Is there a way to reboot or shutdown Windows from a driver? I currently send a message on a port to a user application (actually a service) listening to shutdown/reboot. But, sometimes the user application hangs or has shutdown and it would be easier to just have the driver do the reboot.

Thanks,
Tim


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:


NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></http:></http:></http:></http:></http:></http:></mailto:xxxxx></mailto:xxxxx></https:></mailto:xxxxx></mailto:xxxxx></https:>

> Being “not document” means its not meant to be called by drivers in any case.

Actually, the only thing that “undocumented” means is that it is not supposed to be called by the
third-party drivers, because MSFT may change implementation in the future.However, MSFT-provided drivers are just fine with calling it. As long as this undocumented function is one of NTOSKRNL’s exports, in most cases you are able to link to it directly, without having to obtain its address by other means and calling it by the address. All the problems that one may encounter with it are mainly of theoretical nature,i.e. fall into “what happens if implementation gets changed in some future OS version” class.

However, if function is exported via SSDR, but NTOSKRNL’s export section does not export it in
either Nt… or Zw… form, the function is not supposed by any KM component. First of all, you are unable to link to it, in the first place - you have to call it either by the address or by your own
Zw… stub, i.e.via INT0x2E. No matter which option you choose you are more than likely to get into a serious trouble right on the spot with it, because the function expects a userland caller.

Therefore, my question is in which class NtShutdownSytem() falls - I think it belongs in the latter one (which is, probably, of zero importance in this particular case anyway)…

I’m not sure what that means, but it sounds very scary and ominous.

Well, I meant exactly what I said - in some cases BSOD may leave you with destroyed user data, which is, indeed, “scary and ominous”. The file in itself will still be there, but its contents will be destroyed and overwritten with some gibberish. For example, I managed to successfully destroy C files that were opened in VisualStudio at the time of BSOD, and managed to do so on multiple occasions.The first one was an “accidentental discovery”, so that I decided to check if it was reproducible. In terms of predictability the whole thing worked just in “clock-like fashion”. The FS per se was perfectly fine due to the transactional nature of the way NTFS handles its metadata, but open C files were destroyed and overwritten with plain binary gibberish (IIRC,it was fillled with all zeroes, but I may be wrong here)…

The file system, and its associated user data, will be consistent as of the points of the last flush.
It might not be UP TO DATE. But it will be consistent. Thus guarantees NTFS. Perhaps
that’s what you meant…

You should realize that “first-generation” transactional filesystems like NTFS and Ext3/4 do NOT
guarantee anything in respect of user data. If you want such guarantees you need something more serious, i.e. something like ZFS or BTRFS. These file systems never overwrite anything - they first record new data, change pointers to it in the filesystem all the way to the root, and then update the root. Until FS root gets updated all this FS update is nothing more than just an exercise in scratching on a free space. If something gets wrong you are left with the previous state of FS and user data as if nothing had happened. I think the concept of such approach originates in so-called
“dancing trees” of ReiserFS…

Anton Bassov

On Sat, 5 Mar 2016, Pavel Lebedinsky wrote:

A NULL pointer deref is not guaranteed to bugcheck (it can be handled with try/except). MM_BAD_POINTER will always bugcheck, but it’s mostly intended to catch accidental references. If you want to generate a bugcheck explicitly, call KeBugCheckEx.

To this we can add that if you want to trigger an bugcheck you can also
divide an integer with zero, on NT4 this can be handled with try/except
but on Windows 2000 and later its not possible to catch.

Bo Branten

This distinction matters to you because… You’re going to write an MSFT-supplied driver?

Functions have to be documented in MSDN if they’re called by any component that’s not shipped as part of the base OS. This is regardless of whether the component is supplied by MSFT or not.

Functions remain undocumented for many reasons. ONE of those reasons is that their implementation details may change. Sometimes this is the prime motivation for not doc’ing a function, sometimes this is a (welcome) side-effect of not doc’ing a function for other reasons.

I think you’d be surprised to know that many functions aren’t doc’ed (or not exported, or are missing prototypes) purely because nobody has thought to document them – that is, nobody took the time to make it available because nobody knew anybody cared about it. This has gotten FAR better in past years, since the doc rule I described above was implemented. But it remains true to this day. I’ve seen many cases where just asking the dev owner of a function results in a previously undoc’ed or unprototyped function being made “public”… Of course, I’ve also seen the opposite.

Hence my point: Not relevant.

Peter
OSR
@OSRDrivers

> This distinction matters to you because… You’re going to write an MSFT-supplied driver?

Assuming that one day I have a misfortune to write a driver for Windows I would make such a distinction for the sole purpose of evaluating my potential risks when doing something"unsupported". In case if the target undocumeted function falls in the latter category I would abandon the idea of using it right on the spot, because the potential risk of using it is too high and goes well beyond a simple “what if its implementation gets changed” scenario. Otherwise, I would give an additinal consideration to the potential pros and cons of using it.

For example, as long as a function (even undocumented one) is exported by NTOSKRNL in either Zw Or Nt form I can be 100% sure it will actually return to me. However, I would not necessarily expect it from a function that is not exported by NTOSKRNL but still still exported via SSDT(BTW, ironically, it may be documented for use by the userland). Instead, such a function may assume a userland caller and make an unconditional call/jump to the stub that performs the actual return to the userland.BANG!!!

Anton Bassov

Ok, I finally got a driver signed and working back from MS for Windows 10. Here is what I found out:

  1. You do NOT need a CAT file but you have to reference one in your INF file.

  2. The Microsoft Dashboard hangs if the CAB file doesn’t have an INF file inside or if it is NOT properly formatted. What I mean by hang is it just reports ‘pending’ status forever.
    a. What would be nice if you could but all your binaries into one CAB and MS just sign everything. I can only assume they sign differently to root CA’s based on where the INF files says they are to be placed? Or something?

  3. If you sign the CAB file with an EV Cert but cross sign the drivers not adding a Cert you get an email and the Dashboard informs you to reload the package with properly signed binaries. It would be nice if it would do this every time there is a problem instead of just showing ‘pending’.

  4. I have not been able to get x64 and x32 drivers signed using one CAB and one INF file. I gave up on that, out of frustration, and just submit two packages.

  5. I had a heck of a time getting Windows 10 to recognize the signature at boot time. Everything signed fine, but Windows would not see the signature at boot. I finally got it to work by:
    a. Using an EV Globalsign certificate.
    b. Deleted all my old certificates
    c. Downloaded the cross sign certificate from Globalsign and made sure the signtool referenced it with /ac “.\GlobalSign Root CA.crt” https://support.globalsign.com/customer/portal/articles/1698751-ev-code-signing-for-windows-7-and-8
    d. Installed R1-R3 Cross Certificate from: https://support.globalsign.com/customer/portal/articles/1698751-ev-code-signing-for-windows-7-and-8
    e. Made sure to use the Globalsign timestamp server with the /tr switch and SHA256 here is the command for signing:
    /v /ac “.\GlobalSign Root CA.crt” /n “” /fd SHA256 /tr “http://timestamp.globalsign.com/?signature=sha2” /td SHA256 <%FILETOSIGN%>

    6. Swore a lot about MS changing things, not sure if this help but it made me feel better.

    7. Turnaround time from the Dashboard seems to be 10-20 minutes late at night and around 2 hours during peak times.

    Overall: This is a real pain to get going, at least it was for me. There is a lot of confusion and MS offers little feedback and help. As of today (3/5/16) drivers that I sign with my cert that was issued 11/15 and cross signed still work without using the EV. I cannot make my old cert/cross sign drivers fail on Windows 10 for not being signed. It appears they are still NOT enforcing this. What I would like is to have a clear, did I say CLEAR, answer from MS about this.

    ToDo: I would like to get one CAB file and INF file working for x64 and x32 and earlier versions of my drivers cross signed with SH256 back to XP with a simplified CAB. But for now, I at least have Windows 10 drivers signed and working.

    Other: The new EV Certificate is loaded onto a thumb drive, at least that is how Globalsign works. You cannot load the EV Cert into your store and put away the thumb drive. You have to have the thumb drive mounted and it ask for the Cert password. You can tell it to remember the password, but that works up until you unmount the USB. Physically having to have a USB present really, really, really, dampers my ability to work from multiple sites and PC’s.

    Tim

    From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Kelly
    Sent: Friday, March 04, 2016 9:24 AM
    To: Windows System Software Devs Interest List
    Subject: RE: [ntdev] Kernel driver

    The hang is really when we’re tearing down and rebuilding during updates or reinstall. It’s easier or would be easier to just have the driver reboot. But, just wanted to make sure I wasn’t missing something.

    Thanks

    From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Gabriel Bercea
    Sent: Friday, March 04, 2016 9:01 AM
    To: Windows System Software Devs Interest List
    Subject: Re: [ntdev] Kernel driver

    Well I would say that it is better to just fix that hang you have in your service.
    Apart from NtStudownSystem there is also I believe a bugcheck that actually cleanly shutsdown the system but I cannot recall which bugcheck this actually is.
    Regards,
    Gabriel

    On Fri, Mar 4, 2016 at 2:28 PM, Tim Kelly wrote:
    Is there a way to reboot or shutdown Windows from a driver? I currently send a message on a port to a user application (actually a service) listening to shutdown/reboot. But, sometimes the user application hangs or has shutdown and it would be easier to just have the driver do the reboot.

    Thanks,
    Tim



    NTDEV is sponsored by OSR

    Visit the list online at: http:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at http:

    To unsubscribe, visit the List Server section of OSR Online at http:


    Bercea. G.
    — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at


    NTDEV is sponsored by OSR

    Visit the list online at: http:

    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at http:

    To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></http:></http:></http:>

Thank you again, Mr. Kelly, for the continued updates. I know *I* appreciate hearing people’s detailed experiences; I’m sure others in the community feel similarly.

With Symantec, they put the EV Cert on an eToken (a usb sort of smart card). I believe the EV guidelines require that it be physically stored and thus not able to be duplicated. Or something.

Yes, it’s very annoying.

Peter
OSR
@OSRDrivers

Not being able to extract the private key is why EV certs are more secure. An EV cert token is not just a USB storage device, it’s a crypto processor device with secure storage. Ideally the private key was generated on the crypto chip, never exposed to an external system. When you perform a signature, the signature algorithm runs inside the EV fob, using the private key that was (ideally) generated inside the fob. Ideally, there never was an opportunity for the private key to be on a system where it could have been stolen. I say ideally, as it also is possible to generate the key pairs externally, and import them (with no export facility) into the EV fob.

Before we used EV cert fobs, I would generate the key pair, export it to a file, deleting the original copy. I would then import it back with the option set to not allow exporting. You also could import them into a virtual smart card implemented in a TPM, improving the security level. I’d then store the original key pair on a DVD/USB storage device in a secure place, like a safe.

It’s by design that your ability to do production signatures from multiple machines is hampered, that also means the ability of the bad guys to use your signing key is also hampered if it were stolen, because they don’t have physical possession of your EV cert fob.

Use self-signed test signatures for development use.

Jan

On 3/5/16, 9:56 AM, “xxxxx@lists.osr.com on behalf of Tim Kelly” wrote:

>Other: The new EV Certificate is loaded onto a thumb drive, at least that is how Globalsign works. You cannot load the EV Cert into your store and put away the thumb drive. You have to have the thumb drive mounted and it ask for the Cert password. You can tell it to remember the password, but that works up until you unmount the USB. Physically having to have a USB present really, really, really, dampers my ability to work from multiple sites and PC’s.