[Webinar] Streamline your web hosting managementRegister Today

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 824
  • Last Modified:

Chkdsk STILL running

We have windows 2003 - has been running a CHKDSK for over 16 hours now:
"replacing invalid security id with default security id for file 495200, then 495201 etc.

Should I just let chkdsk complete or can I stop it (cold boot) and try and get access to the server ?
  • 2
1 Solution
I would let it run.....

What kind of raid level are you running on the server?
andrew5499Author Commented:
Server is  blade connected to EMC San - server has 2 mirrored drives for OS...then 2 drives via san for the application.

This happened before when we used a drive on this server to be used as a cloned drive from another server - once we fracture the clone and reboot this server - check disk runs.
Exactly what options did you run chkdsk with ?   I will assume it was with the /f flag only
If the LUN is in the multi-terabyte range, and the EMC is busy, and you have hundreds of thousands or millions of files, then yes, it can take DAYS.  

You need to let it finish, otherwise it won't complete the repair!

Below from Microsoft
    * Read-only CHKDSK will abort before it completes all three phases if it encounters errors in earlier phases and is prone to falsely reporting errors when in read-only mode. That is, CHKDSK may report that a disk is corrupted even when there is no real corruption present. This can happen if NTFS happens to modify areas of the disk on behalf of some program activity that CHKDSK is examining at the same time. To verify a volume correctly, the volume must be in a static state, and the only way to guarantee that state is to lock the volume. CHKDSK only locks the volume when /F or /R (which implies "F") is specified. Thus, you may need to run CHKDSK more than once to get it to complete all stages in read-only mode.
    * System load and whether CHKDSK is running online or during the Windows NT boot sequence can impact the time required to run CHKDSK. CHKDSK is both CPU and disk intensive. Which factor becomes the bottleneck will depend on the specific hardware scenario, but, if heavy disk I/O or high CPU usage is going on concurrent with a read-only CHKDSK, inflated times will result. Also, Autochk.exe runs in a different environment than Chkdsk.exe. While running CHKDSK through Autochk.exe affords exclusive use of CPU and I/O resources to CHKDSK, it also deprives CHKDSK of the benefit of virtual memory. Thus, while Autochk.exe would usually be expected to run faster than Chkdsk.exe, systems with relatively low amounts of RAM may see longer times for Autochk.exe than for Chkdsk.EXE.
    * Fixing corruption adds to the time required. A read-only CHKDSK can complete only if no significant corruption is found. If a disk suffers only minor corruption, the time to fix the problems will be only slightly longer than that required for read-only CHKDSK. But if there is major damage, as might result from a serious head-crash or other major hardware failure, the time required to run CHKDSK can increase in proportion to the number of files damaged. In extreme cases, this could more than double the time required for CHKDSK.
andrew5499Author Commented:
Finally completed. I think it is something to do with a bad cloned drive we have setup with another server.

Featured Post

The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now