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

Home NTDEV
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: https://www.osr.com/osr-learning-library/


When does the iSCSI crash dump driver get invoked?

Ramakrishna_SaripalliRamakrishna_Saripalli Member Posts: 60

a) I installed a 40Gb ethernet card from a major vendor in my server and installed their drivers (NDIS miniport).
They also have a iSCSI crash dump driver that I installed into the registry (in the iSCSIInitiator\Parameters\DumpMiniport type REG_SZ with the name of the driver

The server boots from a local hard disk, pagefile is from the local hard disk.
I mapped a LUN from a NetApp ISCSI server to this server (reachable through the Ethernet port) and mapped it to z: using the iSCSI initiator built into windows
I have configured the session to be persistent across reboot
Then I configured crashdump (for now small memory dump) to be in a folder in z: say z:\foo. I have created z:\foo and rebooted.

Then I ran NotMyFault64 to create a bugcheck but I do not see the crashdump being written to z:\foo.
But if I hook up a wire capture (not wireshark but physical wire capture), I do see SCSI login followed by SCSI writes going out of the Ethernet port.
The MAC address and IP address in the wire capture are correct.
If I configure the crashdump to be the local disk, obviously I have no problems. It gets written to the local disk.

In the debugger, I do not see the iSCSI crash dump driver being loaded at all (I set breakpoints on driver load). When the bugcheck happens, when I do lm to list the drivers, I do not see the driver loaded

a) What is the purpose of the iSCSI crash dump driver? When will that be loaded?. Do I also need to have iSCSI boot on this server?

===================================================================================================================================================

I also am looking for clarification on my understanding of the crash dump process. I derived this from reading Windows Internals edition 6 volume 2 but I have to say I just gleaned it.

This is what I understand happens during crashdump. I am looking for input on my understanding of this process
a) When bugcheck happens, crashdump data gets written to the pagefile
b) The system is rebooted
c) During reboot, while the system is being initialized, the pagefile is copied to the crashdump file

My question is in step (c), if the crashdump is on a iSCSI LUN, does the system use the filesystem to copy the file?. FileSystem internally uses iSCSI protocol.
This assumes that the file system and iSCSI are all initialized and all LUNs are mounted.

How does the pagefile get copied to the crashdump file?

Thanks,
RK

Comments

  • MBond2MBond2 Member Posts: 198

    much of this may be obvious, but just as a starting point

    consider what happens when an unhandled exception occurs. if it happens in a UM process, then the OS will terminate it and clean up all the resources used by that process. It can then write a crash dump to disk using the normal file system etc.

    consider what happens if that unhandled exception occurs in a KM module. There is no lower level of software that can clean up for us, and the only thing we know for sure is that there is some kind of corruption in the state. It might be trivial or it might be extensive. An exception caused by NULL pointer use might happen immediately after a single bad assignment, or it might happen after a megabyte of garbage has been written corrupting the stacks of multiple threads or destroying the internal state of drivers completely unrelated to the one that caused the crash.

    now try to write a crash dump using the normal file system and see what happens. if all of the drivers and services used by those drivers happen to be unaffected by the corruption, then it will succeed, but that is a very big if and not generally true for anything except the most trivial corruption.

    that's why Microsoft created the crash dump stack. special drivers that are intended to run when the state of the kernel is suspect to improve the likelihood that a crash dump can be recorded successfully

    so when you say that you see iSCSI login and traffic, i assume that is not after you generate the fault right?

    yes, i believe that iSCSI boot support is intimatly linked with this process

  • Girish_BasrurGirish_Basrur Member Posts: 97

    You may already be aware of all/much of this, but giving some context:
    Crash dump generation has a few steps before the actual memory.dmp file is generated.
    a. When a crash occurs, the data required for the dump file is first written to the pagefile.sys file. This process is independent of where you say the memory.dmp location should be (z:\foo in your case). If the pagefile is on the local drive, the local HDD controller driver is used to write the contents; if it is on the remote disk (iSCSI LUN in your case), the vendor provided iSCSI crash dump driver is used to write the contents. One exception to the pagefile location requirement is if you use the "DedicatedDumpFile" registry key under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl (Google has more info on this)
    b. For iSCSI, if you are using MS iSCSI initiator along with the vendor provided NDIS miniport, the vendor has to provide a separate iSCSI crash dump driver. The registry key under Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Class{4d36e97b-e325-11ce-bfc1-08002be10318}\ < InstanceID>\Parameters will indicate which driver will participate in the crash dump
    c. On server boot, once the partition that holds the pagefile (or dedicated dump file) is identified, the corresponding driver that is part of crash dump process is copied over as dump_.sys and loaded. This will be the name of the driver to look for when using debugger (say, for lm command). You can set the breakpoints on this driver's DriverEntry to see it getting loaded.
    d. After the crash dump process is complete (writing contents from memory to pagefile.sys/dedicatedumpfile.sys) and the machine is restarted, there is a process that stores the memory information to where you directed the memory.dmp to be stored. This can be different from the location of pagefile.sys/dedicateddumpfile.sys.

    In your case, can you check/confirm the following?

    1. You have either set the DedicatedDumpFile registry or the pagefile is on the iSCSI LUN?
    2. After the machine is booted, which driver is loaded as dump_.sys? If it is the iscsi crash dump driver, can you put a break point at its DriverEntry to see if it is being invoked?

    -- Girish.

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!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE