Hi,

I am working on a keyboard filter driver, but I have one problem: I
don't want the filter to start when in safe mode.
Is there a way for the filter to detect safe mode and abort the
initialisation?
The start type is set to SERVICE_DEMAND_START.

Thanks,
Bevan.

Putting the following in DriverEntry works for us (yes, there are a few
unsafe hacks there, but we only compile this in the debug version):

RTL_QUERY_REGISTRY_TABLE rqrt[2];
NTSTATUS status;
WCHAR wszStr[256];
RtlZeroMemory(wszStr, sizeof(wszStr));
UNICODE_STRING usSystemStartOpts = {0, 256, wszStr};

RtlZeroMemory(rqrt, sizeof(rqrt));

rqrt[0].Flags = RTL_QUERY_REGISTRY_DIRECT;
rqrt[0].EntryContext = &usSystemStartOpts;
rqrt[0].Name = L"SystemStartOptions";
rqrt[0].DefaultType = REG_SZ;
rqrt[0].DefaultData = 0;
rqrt[0].DefaultLength = 0;

status = RtlQueryRegistryValues(RTL_REGISTRY_CONTROL, NULL, rqrt,
NULL, NULL);

// If "SAFEBOOT" found, then we are in Safe mode
// so return error from driver entry.
if (NT_SUCCESS(status)) {
if ( wcsstr(wszStr, L"SAFEBOOT") )
return STATUS_UNSUCCESSFUL;
}

Bevan Collins wrote:

--
Ray

I "forgot to mention" that this fails the device, which might not be
desirable for a keyboard... :-). It's not that great for a mouse either
(though somewhat less painful), which is why we only do it in the debug
version to make our developer's lives easier.

Thinking about it some more, as far as I know, the only way to "not
load" your keyboard filter driver in safe mode and still have the KB
work is to go ahead and load it, notice that you're in safe mode and
change your filter into a simple passthrough that does nothing other
than pass down IRPs (setting all the dispatch routines to some new
simple "do nothing" routine is a common way to do this reliably). It
will still be loaded, but in a mode that you can be pretty sure won't
break anything or add significant overhead.

Anything that causes a filter to fail to load (again, as far as I know)
will fail out the whole device stack. If you consider the alternatives
it will probably be obvious why it's designed that way.

Uhh, well, ok, technically speaking, maybe one could write a very early
boot driver that notices it's in safe mode and removes the LowerFilters
value from the registry before the OS gets a chance to build the KB
stack. Needless to say, I very much *don't* recommend that approach...

Ray Trent wrote:

--
Ray

There is a documented way of finding out whether the system is running in
safemode. Follow this KB:
http://support.microsoft.com/default...5BLN%5D;837643

If you decide not to filter a specific device instance after your filter is
loaded, instead of attaching and staying in a passthru mode, it would be
desirable to not create the filter-deviceobject and attach to the stack and
just return STATUS_SUCCESS from the AddDevice routine. This will keep the
stack rest of the stack functional and the filter driver out of picture.


--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/driver/kernel/KB-drv.mspx

Brilliant, that's just what I was looking for. Thanks Eliyas

Caveat: InitSafeBootMode is not part of Win9x and using it will prevent
your WDM driver from ever loading. If Win9x is important, you can check
for SAFEBOOT in the SystemStartOptions valuename in the registry.

Couldn't agree more. Keep it as clean as possible. Thought some of the
other advice was pretty bogus (failing DriverEntry or still putting a
device object in the chain).

You can also do nothing in AddDevice and return STATUS_SUCCESS. This works.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Ray Trent" <rat@nospam.nospam> wrote in message
news:uUotu093FHA.3628@TK2MSFTNGP12.phx.gbl...

Maxim S. Shatskih wrote:
Sorry about that. For some reason, I didn't remember that.

Anyway, the real point is that, no, there isn't any way to not have your
driver *loaded* in safe boot mode and still have the device work. The
best you can hope for is to have no effect on the device stack. This is
certainly a better way to do that than what I proposed.

--
Ray