Dirty bit not set but chkdsk found/fixed corruptions

  • Thread starter Doug Hoeffel \(eMVP\)
  • Start date
D

Doug Hoeffel \(eMVP\)

Hello:

I'm using XPe SP1 with RAM-based EWF on a HD. Only my NTFS boot partition
is protected by the EWF. I have 2 other NTFS partitions. At startup, my
registry is setup to run chkdsk if the dirty bit is set on my 2 non-EWF
protected partitions. I had a corrupt partition but the dirty bit was not
set, i.e. I did a "chkntfs D:" but the results stated that the dirty bit
was not set. When I ran chkdsk, i..e chkdsk D: /F, it found and fixed
corruptions.

Has anyone seen this before? I don't think this is related to EWF since I
have run tests before to check that chkdsk will run if the dirty bit does
get set. With the EWF enabled, I do a "fsutil dirty set D:" from the cmd
prompt, reboot, and I can see chkdsk run.

TIA... Doug
 
S

Slobodan Brcin

Hi Doug,

I don't know how much I can help with this problem. I had one even worse
experience with one of our test devices. One of driver files protected by
EWF was damaged, but it was caused by bad sector (this things happen, not
often but they do happen).

You probably already checked, but never the less. Have you seen any bad
sectors on HDD?
Did you have power failure or you were testing power loss resilience of your
device?
Why did you suspected in the first place that your partition is corrupted?
Why do you mention EWF, is this just for reference? You are experiencing
problems with unprotected partition, right?
Can you remember what type of corruption was reported?

Regards,
Slobodan
 
D

Doug Hoeffel \(eMVP\)

Sobodan:

The normal usage of my device is to yank the power cord from the wall.

I knew that something was corrupt since as soon as my application would
start to run the process would exit. There was no Dr. Watson crash dump
etc. This seemed odd so I went to look at my Application and System event
logs which are stored on the D: partition (not protected by EWF). Both logs
were corrupt as I got the following message from the Event Viewer:

"Unable to complete the operation on Application. A required privelage is
not held by the client."

The same occured but for the System event log. What was also really strange
is that my Security log, which is normally empty, contained the contents of
what looked like the System event log as it had disk errors etc.

So, I decided to check if the D: partition was marked dirty. The "chkntfs
D:" claimed that the D: partition was not dirty but I ran chkdsk anyway with
the /F. It found and fixed a bunch of stuff but I didn't write down exactly
what. After this, the event logs were fine. My application ran fine after
this.

I don't know if it has anything to do with EWF or not. I was simply stating
that I'm using the RAM based EWF only on C:.

I'm not an NTFS file system expert by any means. I'm curious if there is
anything in the boot partition which is protected by EWF that can effect
anything on other partitions.

Thanks... Doug
 
S

Slobodan Brcin

Doug,

I don't think that NTFS is anywhere documented (at least not publicly), I
know scraps from here and there how some parts of NTFS are working but this
is far from a big picture what it can do, and how it is done.

I don't think that by default NTFS partition has any info that relates it to
other partitions in system.
There is a special case when you can mount volumes to empty NTFS folders,
this is only case that I know in which one NTFS has knowledge of another
partition.
Hardlinks are feature local to each NTFS volume, and can't point to another
volume.
Streams are local to files them self.
I don't think that you use anything from above so you should be clear of
NTFS partition interlink.

So boot partition protected by EWF should not concern you. You could
probably use FAT to gain some small quantity of extra memory and processor
speed.

Currently I can think only following scenario that could maybe explain why
you can't see dirty flag.
Something during the boot cleaned dirty flag maybe chkdsk but it didn't
repair any errors.
So when you run manually chkdsk it found and repaired errors. But you were
unable to see dirty flag since it was already removed.


I don't think that I can give you better explanation at this moment.

For our purpose: I'm using only one NTFS partition for large temporary
files.
And for live video data I have written file system, or better to say single
purpose video data system, adjusted to needs of storing large quantities of
sequential data. If power is interrupted there is no dirty bit or
possibility that data is invalid. If last block write was interrupted, then
this means that I have lost 10 seconds of video from one video source, but
since device need more time to boot, this is not a problem.

I don't think that there is power resilient solution if you use FAT, or NTFS
for logging data.
You can increase data integrity by creating two files with preallocated max
size, but this is also manual work.

Sorry!
Slobodan
 
D

Doug Hoeffel \(eMVP\)

Sobodan:

Thanks for the info. What I'm thinking may have happended is that the NTFS
$logfile data area was corrupt so the dirty bit did not appear to be set.
MS KB article 283340 in the Cause section mentions something about this.

Next time this happens I'll pay closer attention to what files were fixed by
chkdsk.

.... Doug
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top