NTFS file system error needs CHKDSK to fix...
 

First, I know this will seem to not concern Linux, but it does. Really.

I have a situation where an NTFS file system error needs CHKDSK to fix, but I have no way to run CHKDSK, since Windows will not run at all. Always shoots itself in the foot with a BSOD showing the horrid 0x24 (NTFS.SYS-related) error code.

I already knew the file system on my Windows partition was damaged, Microsoft. Good Job! :rolleyes: Now, I've got to somehow manage to run CHKDSK or its close equivalent outside of Windows to correct the errors in the file system. There's only one problem: No apparent way to actually do what I need to do. Booting from a Win7 Recovery Console CD (or Win7 Home Premium SP1 x64 DVD) leads to the exact same BSOD (the one I've described) every time.

All of the tools I've seen thus far correct boot errors. This partition (attempts to) boot, but can't. The HDD's MBR is good, since I get into Linux Mint 17.1 (which I am using right now to type this) just fine. Spinrite 6 certified the HDD hardware to be error-free, so this problem isn't hardware-related.

Running NTFS4DOS does nada. Even their variant of CHKDSK fails to run. If anyone can help, I'd be appreciative. One extremely-frustrated computer tech here.

Nope. Proprietary filesystem - the open source tools can only go so far. If it needs CHKDSK, it needs CHKDSK.
Go find another Win box and plug the drive in to that - "CHKDSK D: /f" (or whatever) will work - may require another boot to get all the handles closed.

syg00 is right, there is no way around this. Pop the drive out and fire it into a USB enclosure and plug it into your buddy's Windows PC. Better yet, don't dual boot. Run Windows in VirtualBox.

As a bonus, the CryptoLocker virus going the rounds these days checks to see if it is running in a virtual environment, and if it is it will shut itself down.

I gave up on dual boot systems ages ago. PITA !

All support for NTFS in Linux is based on reverse engineering. There is no openly available specification for NTFS, which makes it impossible to write an open source NTFS file system check program.

Member response
 

Hi,

You should be able to boot the MS Windows Install media to get to a command line to perform the 'chkdsk /f' on the filesystem via instructions at; An Overview of System Recovery Options for Windows 7 and selecting the repair computer option that will then get you to the command line selection. Once you have the command line then you can perform maintenance on the filesystem.

You should be able to do the same for other versions.

Hope this helps.
Have fun & enjoy!
:hattip:

Okay, what does this have to do with my request for assistance? Seriously... :)

I personally have had zero trouble from dual-booting. In fact, I'm using the Linux-side of the dual boot to respond to this thread. (Heck, I started this thread in Linux...) :D

I was afraid I'd get the consensus I have with this. The problem I'm running into is, quite simply, Windows BSOD's with every boot, no matter if I use a Recovery Console CD (x64, of course) or an installation DVD. While UBCD does launch, it does not have the tools I need to correct this. Was hoping I'd not have to tear the machine down. Toshibas are notorious for being difficult to tear down and put back together, but it looks like that's the best choice right now. Unless I can manage to find a USB sync cable that allows my machine to be seen as a HDD by another Windows box.

What happened when you tried the suggestion above by onebuck? Do you have a windows installation disk?

- until now !

In my experience with dual booting Linux and Windows, exactly the same thing that has happened to you with NTFS happened to me, inevitably.
Another factor was with Linux distro upgrades, which I found could be finicky and concluded that the best way to handle distro upgrades was to strip the drive and start from scratch - which meant doing the whole dual boot thing over again, and then the invariable NTFS blue screen of death.

It may be worth the effort for you, but for someone like me who uses Windows only when they have to - like once a month, I found it was much easier to just single boot, and put Windows in VirtualBox..

Dual Boot just wasn't worth it.

If I was into games on a desktop computer, I'd have two separate physical drives, one Linux one Windows and select the boot drive in the BIOS.

Microsoft OS's behave as if they are the only OS that modifies the MBR, and they don't seem to behave well in that regard.

There is my two cents - it is a PITA for me, maybe not for you :)

Member response
 

Hi,

I use Slackware Gnu/Linux with a secondary drive for my MS Windows install. I only use MS Windows when a client needs assistance. Never have a dual boot issue. Only issue for me was hardware failures but that can be easily handled. Filesystem corruption can happen on any OS, just less likely with a properly dismounted filesystem. On Linux I have the need to perform maintenance on occasions but with MS Windows it has happened more than I care to mention.

Maintenance for MS Windows is easily done by using the install media or recovery disk set. You can use the automated repair or get to the command line to perform the disk utilities such as 'chkdsk /f'. You can use the help system while at the command line for syntax & semantics for a command. The link that was posted earlier; An Overview of System Recovery Options for Windows 7 does provide good instructions for making repairs on a filesystem.

Hope this helps.
Have fun & enjoy!
:hattip:

Two screws hardly counts as a teardown ... :oNo, it doesn't work like that.

Yes, I did, and it shows the exact same BSOD error code (0x24). It's frustrating, because I know the drive hardware is fine, dual-booting had nothing to do with the NTFS filesystem getting messed up (I have my suspicions of what actually caused it, but the company whose utility was involved has not gotten back with me on the issue.), and I was truly hoping a USB cable that allowed my machine to be read as a HDD would be a key, but someone else has already stated "It doesn't work like that." Granted, I think they're incorrect, but there isn't a way to test the theory as yet, since I don't have a USB-A to USB-A cable yet. You see, when I first got this machine, I had such a cable, and the old laptop's hard drive was seen by this machine as just another drive because the two machines were linked via said cable. That is why I believe that if that is the case, I should be able to run CHKDSK on this box from another box.

Now, if I can manage to get VirtualBox to allow me to (temporarily) install Win7 (any flavor), that might prove a solution, but I have my doubts on that, too. I somewhat doubt that a VB-installed OS can actually run filesystem checks on the host drive.

Usually, USB cable connections making a drive available on a foreign system are essentially using the native OS to re-interpret the drive as a mass storage device... So, yeah,... Your friends are correct,... It doesn't work like that.

Your best bet with an NTFS screw-up is to physically mount the drive to a Win 7/8/8.1/10 system and fix it from there. Linux support of NTFS is a reverse engineered hack (for reasons outside of Linux hackers' control),... You need drive management tools that are native to the OS to fix it.

In the future,... DON'T run Windows on bare metal. Run it in a VM instead. If you have to run it native,... Run it on a separate machine, and just connect it to your POSIX-based network...

Sorry for the extended length of time before this response, but when the machine came with Win7 Home Premium and I installed Linux as a dual-boot (in fact, am using said machine's Linux to write this response) I think you can see the problem isn't entirely user error.

What's totally nuts is that I cannot fix the problem at all with the drive mounted in this machine. Running an install image (of Win7 x64, or of a System Recovery image that's also compatible) simply hits the BSOD and errors out. I am highly reluctant to physically dismount the drive, since doing so will disable this machine totally until the drive is physically remounted. I personally think that all file-system developers should make the data for their file systems open-source, so this sort of stupidity doesn't happen. But I've been advised by two different lawyers not to post the letter I've written requesting this very thing. One said "It would generate at least one lawsuit from a certain major company and possibly from as many as three, and you will lose any such suit. Guaranteed." A file system is not an OS; an OS is not a file system. I do not understand why there'd be such a problem.

If it shows the BSOD with the install disk, it's not booting the install disk. Either you don't have the CD/DVD as the first boot device, or something is messed up with hibernate/suspend. Try the BIOS setup program. Take everything out of the boot sequence except the optical drive. Then, disconnect the power and the battery for 1/2 hour.

Then, boot off the Windows installation disk and choose repair.