Problem Reading New Hard Disk D: 160GB

English support forum

Moderators: Hacker, petermad, Stefan2, white

Post Reply
Sparkle
Junior Member
Junior Member
Posts: 4
Joined: 2004-10-01, 14:28 UTC
Location: UK

Problem Reading New Hard Disk D: 160GB

Post by *Sparkle »

Installed a new large hard disk of 160GB on D: as storage.

Whenever I try to access this disk TotalCMD (603) eats memory and locks up the PC requiring a dirty reboot (PC OFF then ON).

The system is a fully patched (to SP1) XP Pro. The Bios recognises the 160GB Samsung HD.

The disk is mounted as an NTFS dynamic drive and was recognised by XP and formatted without error or problem.

Explorer nor any other software seems to suffer from this problem.

Virus software is fitted but not active in memory or otherwise.

This problem never occured with my old second HD of 8GB. No other changes to the PC since HD upgrade.

Any Ideas?

regards
Sparkle
Junior Member
Junior Member
Posts: 4
Joined: 2004-10-01, 14:28 UTC
Location: UK

Post by *Sparkle »

To Add to my above post.

I thought I would move files stored at root of D: to a subfolder using explorer incase there was a problem with file names etc... and then try WinCMD again.

Everything seemed fine (as it does sometimes) until I tried moving (not copy) a file back to the root.

The PC hung whilst WinCMD processed this command and after 4 minutes the file move dialogue appeared and then the process took another 30 seconds.

After this I closed WinCMD normally and carried on with other (non-WinCMD) tasks only to find my PC getting slower and the disk being heavily accessed.

On calling up task manager I see that WinCMD though terminated normally is still resident in memory at least 3 or 4 minutes later and its memory usage was still rising. When it hit 200MB I did a dirty reboot after which all returned to normal.

With this behaiviour WinCMD is useless accessing this 160GB drive now.

Any ideas \ solutions?

Regards
User avatar
Lefteous
Power Member
Power Member
Posts: 9537
Joined: 2003-02-09, 01:18 UTC
Location: Germany
Contact:

Post by *Lefteous »

2Sparkle
Everything seemed fine (as it does sometimes) until I tried moving (not copy) a file back to the root.
Any ideas \ solutions?
In the configuration dialog navigate to "Copy/Delete" and check "use compatiblity mode for the following drives" and enter a * char to indicate you want to use compatiblity mode for all drives.
Sparkle
Junior Member
Junior Member
Posts: 4
Joined: 2004-10-01, 14:28 UTC
Location: UK

Post by *Sparkle »

Lefteous wrote:
Any ideas \ solutions?
In the configuration dialog navigate to "Copy/Delete" and check "use compatiblity mode for the following drives" and enter a * char to indicate you want to use compatiblity mode for all drives.
Thanks for the reply but this did not solve the problem. Took 4 minutes to move a file and 5 minutes after terminating WinCMD I had to reboot as WinCMD was still resident in memory eating 60MB and increasing amount of memory.

My Next move will be to wipe and reinstal WinCMD incase of some corruption or erroneous setting however I do suspect this has something to do with disk size??? as it only started with this HDs installation.

After the reinstall and if no other suggestions I will wipe the disk and reinitialise with a fresh format. Good job I have not yet transfered important files or used this disk as my primary drive yet.

Regards
Sparkle
Junior Member
Junior Member
Posts: 4
Joined: 2004-10-01, 14:28 UTC
Location: UK

Post by *Sparkle »

OK. :oops:

Seems (fingers crossed) that the problem has been located.

I downloaded another non-windows file manager and this too had problems even though explorer itself had non.

After moving a few of the D: files over to my C:\ drive and testing each one there was a single corrupt file. This file probably had come down as an incomplete \ corrupt transfer. On deleting this from the system I am now able to move, delete, rename any file on the D: drive with the normal speed and ease I have come to expect from WinCMD.

What I can't understand is why XP itself had no problem coping and moving (replicating) this erroneous file \ data... but thats life...

Cheers for the response Lefteous.

Not a winCMD \ large hard disk problem after all :oops: but a problem worth noting for future queries of this nature.

Regards
User avatar
SanskritFritz
Power Member
Power Member
Posts: 3693
Joined: 2003-07-24, 09:25 UTC
Location: Budapest, Hungary

Post by *SanskritFritz »

What I can't understand is why XP itself had no problem coping and moving (replicating) this erroneous file \ data... but thats life...
This actually sounds dangerous for me, as it seems Explorer has no problems copying a corrupt file... hmm.
I switched to Linux, bye and thanks for all the fish!
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 50533
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

Sounds like the 128 GB limit discussed here previously. TC tries to copy files in one large piece to avoid fragmentation, so it may have written beyond the 128 GB limit while Explorer didn't. So, are you sure that your motherboard supports disks >128 GB?
Author of Total Commander
https://www.ghisler.com
Jqn
Member
Member
Posts: 171
Joined: 2003-02-26, 16:42 UTC
Location: Madrid (Spain)

Post by *Jqn »

Try this:

Add to register
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Atapi\Parameters

EnableBigLba = 1 (DWORD)

Joaquin
dgshields
Junior Member
Junior Member
Posts: 2
Joined: 2004-10-08, 06:19 UTC

Post by *dgshields »

The BIOS doesn't recognize anything, it merely lists what the HD reports.

If your BIOS doesn't support 48-bit LBA, you will experience odd problems. I suggest opening a CMD prompt and running :

Chkdsk <drive letter>: /r

let this read the entire HD - if you see bad blocks, that meand 48-bit LBA is missing.
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 50533
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

let this read the entire HD - if you see bad blocks, that meand 48-bit LBA is missing.
Not necessarily: Some drives start to read at offset 0 after the 128 GB barrier. And they will also "wrap around" when writing, which can really cause disaster when the root directory and file allocation tables are overwritten...
Author of Total Commander
https://www.ghisler.com
dgshields
Junior Member
Junior Member
Posts: 2
Joined: 2004-10-08, 06:19 UTC

Post by *dgshields »

Really? I've always seen HD's "hit the wall" when the LBA support limit is reached. You're right about "wrapping" as that can really ruin your day.

Thanks!
Post Reply