I need to write some private data at dump time (both hiber and crash) at a private area on disk. As per MSDN, I can insert my filter driver at dump time but that filter driver does not have have any routine to write my own data at some private space on disk. I need to call the same write routine (e.g, hiber_dumpata!IdeDumpWrite or whatever port driver provides) that crashdmp.sys calls. Any suggestions how can I achieve this?
Thank you.
Redesign you need, this is not a simple problem. Either put the data
onto a private device, or accept that it is in the dump file.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@gmail.com” wrote in message
news:xxxxx@ntdev:
> I need to write some private data at dump time (both hiber and crash) at a private area on disk. As per MSDN, I can insert my filter driver at dump time but that filter driver does not have have any routine to write my own data at some private space on disk. I need to call the same write routine (e.g, hiber_dumpata!IdeDumpWrite or whatever port driver provides) that crashdmp.sys calls. Any suggestions how can I achieve this?
>
> Thank you.
Thank you Don. I was able to put the data on a private disk if it is connected to a separate controller where I have my own miniport driver. Any suggestions how can I achieve the same if the private disk is connected to the same controller (with MS/3rd party port/miniport drivers) as boot disk?
Yes you are going to have to reverse engineer the crash dump stack.
First warning this is a pain and of course is different depending on the
OS, for instance XP, vista and Win7 all had differences. Second
warning, if it is one controller you probably want the data on the same
disk, there is no guarantee that everything will work if Disk A has the
dump and Disk B your private data.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@gmail.com” wrote in message
news:xxxxx@ntdev:
> Thank you Don. I was able to put the data on a private disk if it is connected to a separate controller where I have my own miniport driver. Any suggestions how can I achieve the same if the private disk is connected to the same controller (with MS/3rd party port/miniport drivers) as boot disk?
I think there was some “bugcheck callback” which is intended exactly for this.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
>I need to write some private data at dump time (both hiber and crash) at a private area on disk. As per MSDN, I can insert my filter driver at dump time but that filter driver does not have have any routine to write my own data at some private space on disk. I need to call the same write routine (e.g, hiber_dumpata!IdeDumpWrite or whatever port driver provides) that crashdmp.sys calls. Any suggestions how can I achieve this?
>
> Thank you.
>
Max, and that will let you write it to the dump file. This is a
separate disk on the same controller as the dump, that he wants to write
to.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev:
> I think there was some “bugcheck callback” which is intended exactly for this.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> wrote in message news:xxxxx@ntdev…
> >I need to write some private data at dump time (both hiber and crash) at a private area on disk. As per MSDN, I can insert my filter driver at dump time but that filter driver does not have have any routine to write my own data at some private space on disk. I need to call the same write routine (e.g, hiber_dumpata!IdeDumpWrite or whatever port driver provides) that crashdmp.sys calls. Any suggestions how can I achieve this?
> >
> > Thank you.
> >
It could be a separate disk or it could be on the same disk but outside the dump file in a private area - both approach will work for me. Thank you.
I don’t know why you’re trying to do what you’re trying to do, but why not store whatever the data is in some piece of memory within the dump itself? Pre-allocate a page and write some known string to the beginning of the page. It should only take an application a matter of seconds to search the file in increments of 4k to find your data.
Indeed.
KeRegisterBugCheckReasonCallback(BugCheckAddPagesCallback)
Good luck,
mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@oracle.com
Sent: Wednesday, October 27, 2010 4:09 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] writing private data at dump time…
I don’t know why you’re trying to do what you’re trying to do, but why not
store whatever the data is in some piece of memory within the dump itself?
Pre-allocate a page and write some known string to the beginning of the
page. It should only take an application a matter of seconds to search the
file in increments of 4k to find your data.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
>> It should only take an application a matter of seconds to search the file
I cannot have any application (user mode if that’s what you meant) when this private data is used. Also the data may be encrypted by someone like bitlocker which may not be present when I need my private data.
> KeRegisterBugCheckReasonCallback
I think this is only for crash dump. I need to write private data for hibernation also.
These problems can be handled, you will need a simple filesystem
mini-filter to capture the paging file regions and a disk filter that on
startup walks the regions and copies the data to your private area.
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“xxxxx@gmail.com” wrote in message
news:xxxxx@ntdev:
> >> It should only take an application a matter of seconds to search the file
> I cannot have any application (user mode if that’s what you meant) when this private data is used. Also the data may be encrypted by someone like bitlocker which may not be present when I need my private data.
>
> >> KeRegisterBugCheckReasonCallback
> I think this is only for crash dump. I need to write private data for hibernation also.
Hi Don, this private data needs to be used during BIOS environment well before any OS component is loaded.
I did look at some of the assembly of the functions called during hibernation. Also I noticed that there are 2 DUMP_POINTERS versions that need to be supported.
My current strategy is to call hiber_!DriverEntry to get the DumpFunctionPointers like hiber_!DumpWrite and use it to write my own private data from the dump filter just like crashdump.sys does. I’m able to obtain the DumpFunctionPointers successfully but so far no luck on actual writes.
Any suggestions if I’m on the right track? Thank you.
I also noticed that Maxim in one of older threads suggested to look at TrueCrypt which replaces function pointers of the dump drivers to get into dump path. Is it a correct and safe approach for a commerical product? Will it get WHQLed?
Thank you.
> I also noticed that Maxim in one of older threads suggested to look at TrueCrypt which replaces
function pointers of the dump drivers to get into dump path.
Yes, I’ve looked at it pre-Vista, the Vista+ version should have significant updates.
Reverse engineer the fvevol.sys (BitLocker) driver to get some idea on this - it encrypts dumps and hiberfiles.
Probably, on Vista+, you will just need the no-op volume filter somewhere between volsnap and fvevol which will just participate in dump path and do nothing else.
Will it get WHQLed?
I think no such hacks can be WHQLed 
WHQL is only for dumb drivers which do no serious hacks and are only for the hardware piece to appear in Device Manager and proper apps (network and storage miniports are good samples).
I think everything non-trivial, including, for instance, nearly all software-only hardware-less kernel modules, is WHQLable.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks Maxim.
just the dump filters are not useful for my purpose as they have the restrictions of just looking or manipulating the given data buffer. they cannot issue new writes to the dump disk which is my requirement.
>manipulating the given data buffer. they cannot issue new writes to the dump disk
The requirement is, frankly speaking, strange. The normal machine must not BSOD. So, everything related to dumps is debugging instrumentation, and it must be convinient and easy to implement.
To save some amount of debug data to the dump, use bugcheck callbacks.
Also, I have major doubts this is implementable at all. When the dump is done, probably there are no other alive disk drives/storage controllers in a system at all. You cannot allocate kernel memory in the dump path. You cannot build MDLs and IRPs in a dump path. So, I cannot imagine how can you talk to other disks in a dump path.
Hiber path is the same. For your own data to survive hiber/resume, just allocate memory in MJ_POWER handler and it will survive hiber/resume. You can even allocate paged memory (set DO_POWER_PAGABLE in this case).
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
>> When the dump is done, probably there are no other alive disk drives/storage controllers in a system at all. <<
I don’t need any other disk/controllers. just the dump disk to which crashdump.sys is talking.
> You cannot allocate kernel memory in the dump path. You cannot build MDLs
and IRPs in a dump path. <<
My dumpfltr ! DriverEntry gets called at system startup time and I preallocate MDL/Buffer at that time so that is not an issue.
I need to get access to dump_ ! DumpWrite routine to write my private data from my dumpfltr ! DumpWrite routine when it is called during crashdump.
> I don’t need any other disk/controllers. just the dump disk to which crashdump.sys is talking.
And where do you want to write this? to some other location then memory.dmp?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
yes. on a private reserved area on the same disk where the memeory.dmp is written but at a different location than memory.dmp.