Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

Starting a driver registered with SERVICE_DISABLED

omriomri Member Posts: 16

Hey All,
So I'm writing a PCIe device driver using the same PC for both the development and testing. The problem I'm having is that I cannot find any way to actually start the driver without having it automatically start up the next time my PC restarts. That's really important since if I crash the kernel/entire PC inside DriverEntry(), EVT_WDF_DEVICE_D0_ENTRY or EVT_WDF_DEVICE_PREPARE_HARDWARE, the PC will not start back up properly again as it tries to load the same buggy driver over and over and it's a complete pain to get out of this endless cycle.
What I'm trying to do is register my driver with StartType = 4 (SERVICE_DISABLED) in my INF file. That works fine and registers the driver without starting it as expected and shows up in the device manager fine with a caution sign on top of it (I'm simply installing it by right clicking and doing "Install" from file explorer on the INF file right next to my driver SYS file). The problem is I cannot figure out how to actually start the thing. "sc start" gives me error 1058 (ERROR_SERVICE_DISABLED), the service cannot be started, either because it is disabled or because it has no enabled devices associated with it. "devcon restart" at least said it succeeds, but it isn't actually started as I know my DriverEntry() is never called because I never get the output from a DbgPrintEx() statement in my DriverEntry() in the DebugView utility. "devcon enable" before doing "devcon start" doesn't help either. I even wrote a command line utility to start the driver using OpenSCManager(), OpenService() and StartService() to start it and StartService() also fails with error 1058 (ERROR_SERVICE_DISABLED) same as "sc start". I tried using the old OSR Loader utility which can start the driver (to the point of hitting DriverEntry()) but it cannot stop the driver once it's started so it's not of too much use.
Does anybody know a way to start a driver marked with SERVICE_DISABLED in it's INF file? Alternatively, is there another way to load and start a device driver in a way that it won't startup automatically the next time the PC is started?



  • Shane_CorbinShane_Corbin Member Posts: 260

    Is there any good reason you're using the same PC for dev and test? I think you found a good reason not to.

    If you're really hard pressed on hardware you could run Server with Hyper-V and use a VM for your test environment. You'd have to use the Discrete Device Assignment feature to "give" your PCIe to the VM.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,851

    I didn't even know Hyper-V supported device pass through.

    Shows you what I know...

    Thanks, Mr. Corbin, for that tip.


    Peter Viscarola

  • omriomri Member Posts: 16

    Shane_Corbin. For one I barely have the desk space for a single monitor, keyboard and mouse and I dislike the hassle of KVM switching back and forth every minute. At the moment, my company only has a single PC assigned to me. Also my driver is very non standard (it's not a file system, hard disk, network driver or anything else standard) and communicates with user space solely based on custom DeviceIoControl() calls. Thus, I have to keep the source code for the user space controller application and the KMDF driver in sync which is obviously a pain if you're on 2 different machines and I'd like to avoid committing untested source code into git just as a data transfer mechanism.
    There are reasons I'm on a single machine. If I have to, I can probably get set up with a separate dev machine and separate test machine but I'd like to avoid that if at all possible. So far, this problem where Windows restarts the driver for me whether I want it to or not even after it just caused a blue screen of death leading to the restart in the first place has been my only real problem with the single PC approach. Finding a way to load a driver that won't automatically restart when Windows starts seems like far too trivial a request to be not be possible.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,851

    I'd like to avoid committing untested source code into git just as a data transfer mechanism

    I use ”copy” — across the network, to the target machine. Both the driver and the test app together. i create a command file named “c.cmd” that does the copies after a build. Recently, I’ve been using KDFILES to pull a copy of my new driver over to the target machine(now that Mr. Tippet taught me the -m switch) so I only need to copy the app.

    There are reasons I'm on a single machine.

    Of course there are. Just no good reasons.

    I can probably get set up with a separate dev machine and separate test machine

    That’s what you should do. That’s the way driver development on Windows is intended to work.

    Why would you want to subject the file system on your stable development machine to random crashes and potential data loss? No need to answer... it’s really intended to be a rhetorical question.

    Finding a way to load a driver that won't automatically restart when Windows starts seems like far too trivial a request to be not be possible.

    Before PnP it was possible. After PnP, not so much.

    There’s a simple programming solution to this problem, right? If you’re really set on this fool’s errand, have your DriverEntry routine check for and update a registry value. If it’s set when you read it, clear it, write it back to the registry and return an error from DriverEntry. Your driver will thus fail to start. Next time, when you start your driver, the value won’t be set... set it, write it back, and return success from DriverEntry.


    I’ll send you the bill ;-)


    Peter Viscarola

  • omriomri Member Posts: 16

    So I went ahead and hooked up two PCs for a host computer and a test computer. Although nice to have some debugging ability, the basic problem remains of what to do when you brick your machine to the point that windows won't start again if there is a serious problem in your driver's startup code.
    Here is the solution I found which doesn't even require the standard host computer/test computer setup. The key is being able to start your PC in safe mode before your faulty driver blue screens Windows before it fully starts. The problem is that Windows 10 by default no longer supports starting safe mode via the F8 key like older versions of Windows did. Fortunately, you can tweak the OS to reallow it. You can do this with the command "bcdedit /set {default} bootmenupolicy legacy" in a command prompt run as administrator. See near the bottom of the page. After you do that, if you brick your OS, you can simply start it next time in safe mode using the F8 key. It will start Windows successfully in safe mode without the faulty driver loaded. From there you can remove the device (including uninstalling the driver) using the device manager. Then you restart Windows again normally and it starts successfully again without your faulty driver loaded and you can get to the task of fixing the code that caused the driver to crash Windows in the first place.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,851

    Once you have two machines, there are LOTS of things you can do... including using .KDFILES which I mentioned in passing earlier.


    Peter Viscarola

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA