I am working on a ScsiPort/Miniport driver.
Most of the work is done and I want to write the hiberfile to both the
primary master and primary slave devices for redundancy, although the slave
may or maynot have any OS on it.
I know the hibernate path and have used the Crash Write function during
hibernate (called in hiber_(mydrivername)) to write to both the disks. But i
have noticed that the slave device
doesn’t get written. In the hiberfile Write path, i am replicating the SRB
intended for the primary master and changing the srb.targetid for the slave
and doing a
write again on the slave. Is there anyone who can enlighten me more on this
aspect?
Also, is the DUMP_POINTERS structure used to get some information about the
location to dump the hiberfile.sys or is the Hiberfile always written to a
specific LBA/sector in the HDD.
Because i looked for any info on this in the DDK/Net but without any
success, so am leaving this as is.
Besides, i need to debug the code path during writing the hiberfile. I put a
breakpoint ( bp hiber_(mydrivername)!CrashDumpWriteRoutine ) but can’t break
into it while the hiberfile is written.
Can anyone please help on this one?? Waiting for replies.
>Besides, i need to debug the code path during writing the hiberfile. I put
a breakpoint ( bp >hiber_(mydrivername)!CrashDumpWriteRoutine ) but can’t
break into it while the hiberfile is written.
Can anyone please help on this one?? Waiting for replies.
I have done it, and had no problems regarding that. I could check all the
instructions in the function
When do you set the breakpoint? Is there any specific place for that and is
there anything to be done in WinDbg to enable that for something?? I tried
that 2-3 times, but am not able to break at all. Can you provide some more
info on this???
Thanks!
On 11/25/05, Developer wrote: > > > >Besides, i need to debug the code path during writing the hiberfile. I > put a breakpoint ( bp >hiber_(mydrivername)!CrashDumpWriteRoutine ) but > can’t break into it while the hiberfile is written. > >Can anyone please help on this one?? Waiting for replies. > > I have done it, and had no problems regarding that. I could check all the > instructions in the function > > — 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
Get 6.5.3.8 or later. You may want to save the old one if you have problems, but you didn’t say you have tried the latest.
“Hercules” wrote in message news:xxxxx@ntdev… The debugger can’t find the symbols for ntoskrnl.exe properly and defaults for them. Can this be a prb? My debugger version is 6.3.x.x.
“Developer” wrote in message news:xxxxx@ntdev… one problem could be with the symbols, can the debugger resolve the symbols properly?
which version of the debugger are you using?
There is nothing out of the way I did to catch the function call.
On 11/26/05, Hercules wrote: > The debugger can’t find the symbols for ntoskrnl.exe properly and defaults
Most probably that’s the problem after all. Do you have your symbol paths pointing to the Microsoft Symbol server, and verified that the networking is working on the machine with the debugger. If you don’t that’s one of the first things you may want to fix.
> for them. Can this be a prb? My debugger version is 6.3.x.x. > > “Developer” wrote in message news:xxxxx@ntdev… > one problem could be with the symbols, can the debugger resolve the > symbols properly? > > which version of the debugger are you using? > > There is nothing out of the way I did to catch the function call. > > amitrajit > > — > 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 >
I did all the above things but the system seems to hang at Port 80 code =
04h, which i guess occurs just before writing the hiberfile.
Do i need to use a checked build of the OS??
On 11/26/05, R S wrote: > > On 11/26/05, Hercules wrote: > > The debugger can’t find the symbols for ntoskrnl.exe properly and > defaults > > Most probably that’s the problem after all. Do you have your symbol > paths pointing to the Microsoft Symbol server, and verified that the > networking is working on the machine with the debugger. If you don’t > that’s one of the first things you may want to fix. > > > > for them. Can this be a prb? My debugger version is 6.3.x.x. > > > > “Developer” wrote in message news:xxxxx@ntdev > … > > one problem could be with the symbols, can the debugger resolve the > > symbols properly? > > > > which version of the debugger are you using? > > > > There is nothing out of the way I did to catch the function call. > > > > amitrajit > > > > — > > 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 > > > > > — > 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 >
Can anyone provide some help on this one??? On a checked build, system seems
to be in a state of hang after i give the hibernate command from windows and
before the hiberfil is getting written. I have set breakpoints in the
hiber_(mydrivername).sys file which gets loaded sometime before the
hiberfile gets written and the debugger is also able to locate its symbols (
i.e. it sets a breakpoint at the code of my driver), which i am able to see.
My purpose is to just debug the code when the actual hiberfil is getting
written to the disk. Specifically the CrashDumpWrite callback routine in my
port driver. Am really confused if i am just chasing ghosts here, somebody
in this group said here that he’s done that.
I want to get the LBA’a/Sector’s that are used to write the hiberfile to and
then go back to windows/DOS and check that on both the primary master and
slave drives and compare. If they are same my work is over, if not i need to
debug the hiberfil writing code for a failure condition there. At present i
am just replicating the SRB created for the master except for the target id,
and writing to the slave drive. Master gets written properly, i need to
verify the slave writing.
Otherwise, i may have to think of some other method to find out whether the
hiberfile IS getting written to the disks or not (which is my intention).
Would really appreciate some help!
Thanks!
On 11/28/05, Pritam wrote: > > I did all the above things but the system seems to hang at Port 80 code = > 04h, which i guess occurs just before writing the hiberfile. > > Do i need to use a checked build of the OS?? > > > On 11/26/05, R S wrote: > > > > On 11/26/05, Hercules wrote: > > > The debugger can’t find the symbols for ntoskrnl.exe properly and > > defaults > > > > Most probably that’s the problem after all. Do you have your symbol > > paths pointing to the Microsoft Symbol server, and verified that the > > networking is working on the machine with the debugger. If you don’t > > that’s one of the first things you may want to fix. > > > > > > > for them. Can this be a prb? My debugger version is 6.3.x.x. > > > > > > “Developer” wrote in message > > news:xxxxx@ntdev… > > > one problem could be with the symbols, can the debugger resolve the > > > symbols properly? > > > > > > which version of the debugger are you using? > > > > > > There is nothing out of the way I did to catch the function call. > > > > > > amitrajit > > > > > > — > > > 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 > > > > > > > > > — > > 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 > > > >
Sorry for delaying on this. I was out of office for 4 days. Well, I still am
not sure what exactly the problem is with your debugger.
When my team did the debugging, we did you the Win2K pro checked build
(partial) and the COM ports to debug. the debugger version was 6.3
I infer (from what you said about not finding the breakpoints) as a symbol
resolve problem. However try this…
Set the break point in hiber_(your_driver)!DriverEntry and in
hiber_(your_driver)!AtapiCrashDumpOpen if you can catch them ( as you must
have over ridden them also) you should be able to catch the rest. Also just
in case it is a symbol problem, you may try to manually fetch the address of
the function and set the break point there.
******If it is the not the symbol, then actual problem is that WINDOWS
DISABLES debugging interrupts somewhere in the hibernation process, thus all
break points are disabled. We jumped that part of the kernel code and got
some magnificiant results.*******
I am using the WinXp-Sp1 pro Checked Build from MSDN and also the symbols
look to be proper because it doesn’t throw any error while setting the
breakpoint for hiber_(mydriver) in any routine. And i am putting the bp’s
just before the hiberfil is written and before the debugger loses control
(which is obvious). Besides i tried putting a breakpoint at the function
address for hiber_(mydriver)!DriverEntry as you said, but still the system
sort of hangs just before hiberfil writing.
I think the second part that you said about Windows disabling debugging
interrupts is the missing part. Can you help me in bypassing that part of
the kernel code, if that is something you can share. To be able to do that
and debug the hiberfil writing code path would help me a lot.
Thanks!
On 11/30/05, Developer wrote: > > Pritam, > > Sorry for delaying on this. I was out of office for 4 days. Well, I still > am not sure what exactly the problem is with your debugger. > > When my team did the debugging, we did you the Win2K pro checked build > (partial) and the COM ports to debug. the debugger version was 6.3 > > I infer (from what you said about not finding the breakpoints) as a symbol > resolve problem. However try this… > > Set the break point in hiber_(your_driver)!DriverEntry and in > hiber_(your_driver)!AtapiCrashDumpOpen if you can catch them ( as you must > have over ridden them also) you should be able to catch the rest. Also just > in case it is a symbol problem, you may try to manually fetch the address of > the function and set the break point there. > > If it is the not the symbol, then actual problem is that WINDOWS > DISABLES debugging interrupts somewhere in the hibernation process, thus all > break points are disabled. We jumped that part of the kernel code and got > some magnificiant results.* > > Best of luck and keep me posted, it this helps. > > amitr0 > — 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 >
>but still the system sort of hangs just before hiberfil writing.
Are you sure it *hangs*, bcause the write function is called several times
as it dumps part of the memory into the disk at a time. IIRC, it makes a
temporary buffer, copies a part of the memory there, does a CRC check of it,
dumps it to the disk, and redoes the CRC check and then clears the buffer
and all these steps are repeated several times depending on the amount to
data to be dumped. So what might seem to be a hung state may not be one, I
don’t know how long you waited, or what test methods you used to detect a
hang, this is just based on my personal experience.
I think the second part that you said about Windows disabling debugging
interrupts is the missing part.
Yes, seems like you are where I was a stuck some time back. Well, just trace
all calls before hiber_(YourDriver)!DriverEntry also. What I can say is,
there are several other functions that come into the picture before the
second copy of the ATAPI driver is loaded, I am not sure where exactly the
disabling occurs ( forgot ), but it DOES occur.
Keep trying, I could do it, and I AM sure you can also. But I think that you
need to check deeper into the calls than just putting break points into the
driver do a string search on atapi with with words like ‘hiber’, ‘dump’,
‘crash’ etc and see the list of functions, many of them are called before
the copy of the bus driver is loaded, they do a lot of crappy things with
the kernel.
Thanks for helping. I actually can write to the slave disk now and so am
pass this stage, although didn’t need to debug the hiber write code path.
But will try this anyway, whenever i need it again.
But from what u said, i think, i need to debug the ScsiPortNotification()
function and the values passed to it for SCSI_NOTIFICATION_TYPE.
Specifically CallDisableInterrupts etc.
I may be completely wrong, just throwing ideas in the air.
Thanks!
On 11/30/05, Developer wrote: > > >but still the system sort of hangs just before hiberfil writing. > > Are you sure it hangs, bcause the write function is called several times > as it dumps part of the memory into the disk at a time. IIRC, it makes a > temporary buffer, copies a part of the memory there, does a CRC check of it, > dumps it to the disk, and redoes the CRC check and then clears the buffer > and all these steps are repeated several times depending on the amount to > data to be dumped. So what might seem to be a hung state may not be one, I > don’t know how long you waited, or what test methods you used to detect a > hang, this is just based on my personal experience. > > >I think the second part that you said about Windows disabling debugging > interrupts is the missing part. > > Yes, seems like you are where I was a stuck some time back. Well, just > trace all calls before hiber_(YourDriver)!DriverEntry also. What I can say > is, there are several other functions that come into the picture before the > second copy of the ATAPI driver is loaded, I am not sure where exactly the > disabling occurs ( forgot ), but it DOES occur. > > > Keep trying, I could do it, and I AM sure you can also. But I think that > you need to check deeper into the calls than just putting break points into > the driver do a string search on atapi with with words like ‘hiber’, ‘dump’, > ‘crash’ etc and see the list of functions, many of them are called before > the copy of the bus driver is loaded, they do a lot of crappy things with > the kernel. > > Write back if you need anything more… > > amitr0 > > — 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 >
might be, I am not sure, cause I was working on a different project on
hibernation, and the path taken to reach the disabling interrupts part might
be diff, nevertheless, if you can patch the function it should take care of
things.
Do let me know. I am immensely interested in knowing how you are doing,
interesting project you have in hand man.
Will surly let you know, if i am successful in debugging the hibernate code
path. Presently i am in a different kind of a fix, so am not able to
concentrate on that!
On 12/2/05, Developer wrote: > > might be, I am not sure, cause I was working on a different project on > hibernation, and the path taken to reach the disabling interrupts part might > be diff, nevertheless, if you can patch the function it should take care of > things. > > Do let me know. I am immensely interested in knowing how you are doing, > interesting project you have in hand man. > > — 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
), but it DOES occur.