2

I'm trying to develop a dual purpose driver that performs certain tasks at boot time, and other unrelated tasks after Windows has already started. It's developed as a boot start driver. I understand that the proper way to do this may be to develop 2 separate drivers, but I'd prefer to only go through the WinQual process once. There's also the added benefit of performing only one driver install in my app versus two. It needs to work on Vista through Win8 x86 & 64.

So what I'm really looking for is a safe way to determine in DriverInit if the system is in the process of booting, or if it's already up and running. The driver will initially be utilized when Windows has already started, then enabled at boot time after the next reboot. The DriverInit code needs to be different for both scenarios.

Is there a registry key that is or is not present?

Can I determine if a user is logged-in in DriverInit?

Is there a call I can make that will determine if Windows is booting?

I'm not an expert at driver writing, so thanks in advance for any advice.

Randall Deetz
  • 512
  • 4
  • 25

4 Answers4

1

Technically, glagolig's answer is probably the correct way to solve this.

The solution for my particular issue was a little different. There are 2 mutually exclusive use cases were the driver is either needed as a SERVICE_DEMAND_START driver after Windows is up and running, or as a SERVICE_BOOT_START driver with boot time functionality. The situation never arises were I need the functionality of both cases at the same time in the same Windows session.

The driver is initially installed as a SERVICE_DEMAND_START driver (this is the one that is going to WinQual). It is then changed to SERVICE_BOOT_START in the registry on the new drive that will be booted. All the driver entry points (DriverEntry, AddDevice, etc) that are different for each use case read the 'Start' value in the driver's service registry key to determine how it needs to operate.

It hasn't passed yet, but I'm fairly certain that I can change the start type of the driver in the registry without affecting Window's digital signature enforcement.

Randall Deetz
  • 512
  • 4
  • 25
  • I think this is the correct solution for your use-case, though your question didn't make your situation entirely clear. – Harry Johnston Aug 03 '13 at 11:17
  • The driver has now passed WinQual. My signed driver can now function as demand start or boot start. Certification allows for the initial install without the ugly popup warning to the user. It also allows the driver to load at boot time without crashing. Before certification, the driver crashed the system at boot time if I didn't have 'testsigning' enabled in bcdedit. – Randall Deetz Aug 19 '13 at 10:45
0

I've answered a similar question elsewhere on SO. The short version is that what you're asking is not normal driver behavior, so no API exists to support this. You can add in heuristics to tell you this, but they'll remain heuristics.

Community
  • 1
  • 1
Daniel Goldberg
  • 19,908
  • 4
  • 21
  • 29
  • I'm wondering if I can read a value in HKEY_CURRENT_USER to determine this? At boot time, this key shouldn't exist. – Randall Deetz Jul 18 '13 at 16:26
  • Oops, looks like HKEY_CURRENT_USER is not available to kernel mode drivers. – Randall Deetz Jul 18 '13 at 17:04
  • Of course it's not, HKEY_CURRENT_USERS is a symlink that lives a specific sessions object namespace that points to the logged on HKEY_USERS subkey. If you want to *cheat* that way, you can check if the SID for LOCAL_SERVICE is loaded under HKEY_USERS. Note this is ANOTHER heuristic and I can quickly setup a workstation such that this won't work. – Daniel Goldberg Jul 19 '13 at 21:30
  • Cheating is OK, because it's not like the system will crash if the driver can't detect this properly. The driver is used to convert a removable media device to a fixed disk. The fixed disk in question can later be booted. When it's booted, I want to enable pagefile capability. I'm currently looking at the IRP_MJ_PNP msgs to see if they are different at boot time versus what is sent to the driver when Windows is up and running. – Randall Deetz Jul 19 '13 at 23:41
  • They won't be. If that's all you want to do, then you don't need to recognise "boot time". Look into triggered loading, see MSDN http://msdn.microsoft.com/en-us/library/windows/desktop/dd405513(v=vs.85).aspx – Daniel Goldberg Jul 20 '13 at 09:37
0

At the time boot-start drivers are loaded Windows has not created any user-mode processes yet. Try to acquire a handle to some process that is supposed to be created later on during Windows startup. For example, smss.exe, csrss.exe or wininit.exe . (Processes with these names existed for many years, it is very unlikely that Microdoft abandons them in the future while still allowing existing kernel mode modules to run.) Use ZwOpenProcess with POBJECT_ATTRIBUTES pointing to one of those process' names. If the call fails you are at boot time.

Also you may study Windows startup described in "Windows Internals" by Russinovich and Solomon. Most likely you will get a number of other ideas.

glagolig
  • 1,100
  • 1
  • 12
  • 28
0

You can use IoGetBootDiskInformation to check if you are loaded post or, during boot. It will return STATUS_TOO_LATE if this API is called post reboot.

satishmallik
  • 1