nobus
asked on
why chkdsk ?
everytime i connect a windows 10 drive to a windows 7 system - as second drive - it starts running chkdsk
this happens also when i connect a windows 7 drive to a windows 10 system as second drive
of course - it NEVER finds an error - but it takes a lot of time
why is this? can i stop that behaviour ? if so - tell me how please !
this happens also when i connect a windows 7 drive to a windows 10 system as second drive
of course - it NEVER finds an error - but it takes a lot of time
why is this? can i stop that behaviour ? if so - tell me how please !
ASKER
all connected directly to sata ports
i often connect a drive, to copy files and folders - that's how i get to have the problem
i often connect a drive, to copy files and folders - that's how i get to have the problem
If you disconnect while on power, that might happen.
The reason if dirty bit flag.
Manually Reset or Clear Dirty Bit in Windows without using CHKDSK
Disable or Stop Auto CHKDSK During Windows Startup
Manually Reset or Clear Dirty Bit in Windows without using CHKDSK
Disable or Stop Auto CHKDSK During Windows Startup
ASKER
no disconnect with power on
i know it has a dirty bit flag - but why ?? THAT is my question
i know it has a dirty bit flag - but why ?? THAT is my question
I am not sure why that is happening, I had that same issue long time ago with XP and Vista (every time when rebooted or shutdown and then boot to other OS it would perform checkdisk). At that time I found some explanation why that is happening, I tried, but I can't find it now.
Just as a side note, to mention that I noticed brand new swapfile.sys file on system drive, and in last few months it is happening that I shut down Win10, and when I power it up in the morning applications that were running previous night can be already on. Today, for start, I disabled hibernation to see if it will happen again, or maybe swapfile.sys has something do with it.
Beside why, you asked how to prevent it. It is listed on the link above how to prevent it.
:)
Just as a side note, to mention that I noticed brand new swapfile.sys file on system drive, and in last few months it is happening that I shut down Win10, and when I power it up in the morning applications that were running previous night can be already on. Today, for start, I disabled hibernation to see if it will happen again, or maybe swapfile.sys has something do with it.
Beside why, you asked how to prevent it. It is listed on the link above how to prevent it.
:)
There was an issue some years back that I only vaguely remember. It involved taking NTFS volumes from one system to another where the systems were at different releases of Windows.
Each system on seeing the drive would rewrite part of the NTFS header block to its own satisfaction, which resulted in the earlier release operating system being dissatisfied at seeing a higher revision level of the NTFS header structure. It only occurred when the drive was going from a later release of Windows to an earlier release, though, if I remember right.
Each system on seeing the drive would rewrite part of the NTFS header block to its own satisfaction, which resulted in the earlier release operating system being dissatisfied at seeing a higher revision level of the NTFS header structure. It only occurred when the drive was going from a later release of Windows to an earlier release, though, if I remember right.
Apparently the dirty bit is not cleared by chkdsk on these drives and thus chkdsk tries again and again to scan and clear it.
Did you perform CHKDSK x:/f or /r?
If yes and this did not help then I would use the bulky approach - copy out the data from these drives and delete the partitions - re-create them.
Did you perform CHKDSK x:/f or /r?
If yes and this did not help then I would use the bulky approach - copy out the data from these drives and delete the partitions - re-create them.
ASKER
i know how to clear the dirty bit - that's not the solution
the question is how to prevent that the dirty bit gets set - then you don't have to clear it
Dr Klahn - that is my opinion also - different OS versions are the cause - but i'm not sure
Noxcho "Apparently the dirty bit is not cleared by chkdsk on these drives" yes it is
>> Did you perform CHKDSK x:/f or /r? << i did nothing - it autoruns on startup
the rest of your comment does not help with my problem
the question is how to prevent that the dirty bit gets set - then you don't have to clear it
Dr Klahn - that is my opinion also - different OS versions are the cause - but i'm not sure
Noxcho "Apparently the dirty bit is not cleared by chkdsk on these drives" yes it is
>> Did you perform CHKDSK x:/f or /r? << i did nothing - it autoruns on startup
the rest of your comment does not help with my problem
Use a Linux Live OS disc and move those files over instead. Neither chkdsk nor weird permission issues that way. Then reboot to Windows.
ASKER
i don't need to move any files - i only want to know why chkdsk is started in that scenario
Does this occur from Windows 10 to Windows 10?
What about major version differences between Windows 10 systems?
What about Windows 7 to 8/8.1 and vice-versa?
What about Windows 8 to 8.1 and vice-versa?
What about Windows 8 to Windows 10 and vice-versa?
Hypothesis: I side with Dr. Klahn and you. I think NTSF headers come into play.
So can one stop it from happening? Maybe not.
I wonder if you could bypass chkdsk as a workaround...
Using the Registry Editor before inserting the secondary drive, try:
Run regedit to open the Registry Editor and navigate to the following key:
Autochk on boot is meant to catch drives with a dirty bit. I say workaround because this will prevent the system from checking that drive letter for a dirty bit in the future.
What about major version differences between Windows 10 systems?
What about Windows 7 to 8/8.1 and vice-versa?
What about Windows 8 to 8.1 and vice-versa?
What about Windows 8 to Windows 10 and vice-versa?
Hypothesis: I side with Dr. Klahn and you. I think NTSF headers come into play.
So can one stop it from happening? Maybe not.
I wonder if you could bypass chkdsk as a workaround...
Using the Registry Editor before inserting the secondary drive, try:
Run regedit to open the Registry Editor and navigate to the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
Change the BootExecute entry from:
autocheck autochk * /r\DosDevice\C:
To:
autocheck autochk /k:D /k:E /k:M *
or whatever drive letters which the system might label the 'secondary drive' as, to exclude from chkdsk.Autochk on boot is meant to catch drives with a dirty bit. I say workaround because this will prevent the system from checking that drive letter for a dirty bit in the future.
Sorry for the multiple edits; Let me know if the final draft workaround above, bypasses the chkdsk on boot.
ASKER
i don't know if it happens with other OS versions - i don't have them to test with
bypassing chkdsk is too late - i just want to know why it runs - and if there is something i can do so it never runs anymore
btw -i don't know the drive letters, since i hook the drives in different locations and systems
i also think its an NTFS header problem - maybe the fast start option?
bypassing chkdsk is too late - i just want to know why it runs - and if there is something i can do so it never runs anymore
btw -i don't know the drive letters, since i hook the drives in different locations and systems
i also think its an NTFS header problem - maybe the fast start option?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
since you backed that up with a link to others in this situation, i' take it as best answer
It would help if we knew the nature of the drives. Are they internal connected via the motherboard, or external connected via USB?
Pure speculation:
The drives in question are external drives and were not ejected from the host system when the USB cable was detached. This leaves the dirty bit set on the drive. When taken to another system it sees the dirty bit and launches chkdsk.