Is it possible for ZwCreateFile to bluescreen the machine?

-Maybe early during system startup, on a corrupted file
system?

My PASSTHRU-based miniport Ethernet had been running
flawlessly for about half a year (many successful reboots,
on many different Windows 2000 Server machines) when it
suddenly started bluescreening on every startup on one
machine. An attached kernel debugger showed that
ZwCreateFile caused the bluescreen. This is called from
PASSTHRU's DriverEntry() to create a new log file on the
disk.

I have very little information, since there was no
MEMORY.DMP created, and we could suddenly no reproduce
this anymore.

If anyone can give me any clue on what could have caused
the blue screen, I'd be happy to hear any theories.

Some info:

* Disk was not full (34GB left)
* it bluescreened on EVERY boot, in ZwCreateFile()

BugCheck:
UNEXPECTED_KERNEL_MODE_TRAP
code 8 = Double Fault
(caused by passthru.sys, according to WinDbg !analyze -v)

Partial stack trace:

FsRtlUninitializeOplock <-- bugchecked here
PrepareFcbForRemoval
NtfsDeleteScb
....
ZwCreateFile

-Is this stack trace 'normal' or does any function name
here indicate a problem with the hard drive/file system?

* I booted the machine in safe mode, disabled all
PASSTHRUs (using Device Manager), and from then on the
machine booted up fine. Unfortunately, by re-enabling the
PASSTHRUs I could not get the machine to bluescreen
again...and there's no crash dump file.

- Is it too early to call ZwCreateFile from DriverEntry()
on a network miniport driver? I have noticed that it's too
early to create events, so maybe it's unsafe to create
files at this point too?


ANY comments appreciated - thanks!

/ Hannes.

Double fault means that the kernel stack was overrun. I'm betting you
had third-party products on that machine that installed filesystem
filters, such as anti-virus products.

It's OK to call the Zw* file APIs in DriverEntry as long as you're not
marked as boot start. However, PnP drivers are usually marked as demand
start and are loaded by PnP whenever it wants. Not sure when you can
expect network miniport drivers to load - Maxim?

Hannes wrote:

--
- Nick Ryan (MVP for DDK)

Depends on path. Use only \SystemRoot\xxx style paths for this.

Max

PnP drivers - which are not Boot start - are System start, not Manual.

Since IMs are miniport drivers, and thus are PnP drivers for some
root-enumerated devnodes, they are loaded approximately at the same stage. At
this stage, there is no guarantees that any FS paths are valid except
\SystemRoot.

Only in pre-PnP NT4 networking was Automatic/Manual start. In later NTs, it is
System.

Max

My PASSTHRU DriverEntry() function calls ZwCreateFile() to
create a file in \DosDevices\C:\...etc - so that is a bad
idea, then?

It's funny that this is the first time we see it fail, in
about half a year.

/ Hannes.

Can anyone also please let me know if ZwCreateFile should
_normally_ end up (about 10 levels down the stack) in
function FsRtlUninitializeOplock() ?

Or, is the fact that this function got called indicating
some kind of problem with ZwCreateFile?


Thanks,

/ Hannes.

You're sure about this? From an MSDN article about driver load order:

"Drivers should follow these rules for specifying StartType:

PnP driver
A PnP driver should have a start type of SERVICE_DEMAND_START (0x3),
specifying that the PnP Manager can load the driver whenever the PnP
Manager finds a device that the driver services."

And from the DDK:

"If the miniport driver for the NIC is not already loaded, the PnP
Manager loads the driver and then calls the miniport driver's
DriverEntry function. If the driver is already loaded, processing
continues with Step 4."

My 3COM driver, for example, is marked demand start.

Maxim S. Shatskih wrote:

--
- Nick Ryan (MVP for DDK)

Sure, it's normal. FSD's like NTFS are extremely complex and consume
lots of stack space to do the good stuff that they do. But they should
function fine as long as the drivers above them don't also consume an
inordinate amount of stack space. You may want to assert that
IoGetRemainingStackSize() returns some reasonable value (say more than
2K) before you call ZwCreateFile.

Hannes wrote:

--
- Nick Ryan (MVP for DDK)

And latter from the same documentation page:

"
1.. On system boot, the operating system loader loads drivers of type
SERVICE_BOOT_START before it transfers control to the kernel. These drivers are
in memory when the kernel gets control.
Boot-start drivers can use INF LoadOrderGroup entries to order their loading.
(Boot-start drivers are loaded before most of the devices are configured, so
their load order cannot be determined by device hierarchy.) The operating
system ignores INF Dependencies entries for boot-start drivers.

2.. The PnP Manager calls the DriverEntry routines of the SERVICE_BOOT_START
drivers so the drivers can service the boot devices.
If a boot device has child devices, those devices are enumerated. The child
devices are configured and started if their drivers are also boot-start
drivers. If a device's drivers are not all boot-start drivers, the PnP Manager
creates a devnode for the device but does not start the device yet.

3.. After all the boot drivers have loaded and the boot devices are started,
the PnP Manager configures the rest of the PnP devices and loads their drivers.
The PnP Manager walks the device tree and loads the drivers for the devnodes
that are not yet started (that is, any nonstarted devnodes from the previous
step). As each device starts, the PnP Manager enumerates the children of the
device, if any.

As it configures these devices, the PnP Manager loads the drivers for the
devices, regardless of the drivers' StartType values, and starts the devices.
Many of these drivers are SERVICE_DEMAND_START drivers, but they can have any
StartType.

The PnP Manager ignores registry entries that were created as a result of INF
Dependencies entries and LoadOrderGroup entries for drivers that it loads in
this step. The load ordering is based on the physical device hierarchy.

At the end of this step, all of the devices have been configured, except
devices that are not PnP-enumerable and the descendants of those devices. (The
descendants might or might not be PnP-enumerable.)

4.. The PnP Manager loads drivers of StartType SERVICE_SYSTEM_START that are
not yet loaded"
So, all PnP drivers are loaded before the non-PnP System start drivers, and the
StartType for PnP drivers is nearly irrelevant (it is only relevant whether
this is Boot or not). This matches the observations in the debugger.

Max

Yes, since "C:" symlink can be not initialized yet.

You can only use \SystemRoot path on so early a stage, which only gives you
access to the Windows installation directory.

Max

This is because "\BaseNamedObjects" is not existing yet.
This is one of the causes why named events are not recommended.

Max