Karthikeyan,
On the one hand you are using the term "miniport" then you are talking about "your" bus driver, so I'm not sure exactly hou to answer all your questions. However, if this is a ScsiPort or StorPort miniport driver, note the following.
1. When writing the crash dump or hybernation file, Windows uses a second copy of your miniport driver. There is also a simplified port driver called diskdump.sys. When you look for loaded modules in the debugger, you should be able to find the copy of your miniport; it has a similar name with some extra characters in front of it, somethink like dump_, I can't recall exactly.
2. Note that if your normal miniport driver grabs a lot of memory, you will have to cut this way back for the dump driver. I can't recall exactly how much but seems like 32k or some such is the max.
3. You can tell in your code that you are running as part of the dump or hybernation process by looking at the Arguments argument to FindAdapter. If it is a non-null pointer and the string passed in is "dump=1", you are running the dump copy of the driver. Also, in DriverEntry, if the passed in DriverObject and Argument2 arguments are NULL, you are in dump mode.
4. Make sure at least your boot device is accessible before you exit your HwScsiInitialize routine. Windows is not going to wait to send commands to your boot device and expects it to be available immediately.
5. If you are doing any polling and checking time by calling KeQuerySystemTime, that's not going to work during the dump process; you will need to implement something using the Performance Counter functions.
6. Not sure why, but if you are in dump mode, you want to disable MultipleRequestsPerLu.
7. Don't call any Registry functions if you are in Dump Mode.
8. Disregard any HwScsiResetBus calls if you are in Dump Mode.
9. If this is StorPort, and you have implemented a DPC, you have additional problems. Instead of queuing the DPC, call its function directly.
10. Make sure your boot device appears at the same TargetId and LUN as it did in the main driver.
As for debugging the dump copy, I have never done this, but you might try putting a hard coded breakpoint in your DriverEntry. You will have to proceed through it during system startup, but when the dump process starts, you should hit it again.
I don't know where any of this is documented, we had to find it all the hard way.
Hope all this helps.
Jerry
xxxxx@lists.osr.com wrote: -----
>To: "Windows System Software Devs Interest List"
>
>From: "Karthikeyan Manoharan"
>Sent by: xxxxx@lists.osr.com
>Date: 03/28/2005 12:34AM
>Subject: [ntdev] Debuggin scsi miniport supports for crash dump
>file.
>
>
>All,
>This query is regarding Windows 2003 SCSI miniport driver support for
>crash dump file.
>I have a Windows 2003 system booted over the FC boot LUN from my
>adaptor, Windows boots from the LUN of this adaptor and page file is
>also stored in this FC boot LUN.
>Now I want to support crash dump files. I made sure my bus driver
>which enumerated this SCSI miniport device supports
>IRP_MN_DEVICE_USAGE_NOTIFICATION and notification type
>DeviceUsageTypeDumpFile .
>
>When there is a crash (BSOD), dump file is not getting created. Even
>if automatically reboot flag in advanced option is set, system
>doesn?t reboot after crash it stays there. No data transfer is
>happening to LUN.
>
>Here are my queries,
>i) Is there any way I can trace the dump file
>creation process. Can I debug the creation of crash dump file
>(diskdump.sys)
>ii) Is there any checklist for support of crash
>dump files, I want to make sure I am not missing any flags/ IRP etc
>Regards
>Karthikeyan M TOPSPIN COMMUNICATIONS
>TECHNOLOGIES (I) PVT. LTD
>Sr. Software Engineer Block 1, 1 st Floor,
> Tel:+91-80-51369324 ESQUIRE CENTRE, MG ROAD
>
> Bangalore - 560
>001. INDIA .
>
>
>---
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: unknown lmsubst tag
>argument: ''
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>