HD damage or ?

D

David H. Lipman

From: "Navyguy said:
I ran a full scan with Malware bytes Anti-malware which completed
successfully and found nothing.

In passing, will Malwarebytes Anti-Malware conflict with Spybot or
Spywareblaster or Avira or cause the computer to slow down? Should I
leave it on the computer? Is there a danger of having too much?

@ J.P. Giiliver (John) - I forgot that my vintage of computer it
fractures HD’s above a certain size into two partitions. My 160 GB HD
after formatting and partitioning fractured into two partitions of 127
GB and 33 GB. It seems they didn’t envisage the computer needing more
memory when they wee made and so when it reaches it maximum it
fractures the drive into (2) partitions by default. I’ve never used
the smaller partition before but perhaps instead of adding another
drive I should use that instead and save the 40GB HD as a backup.

@Paul – I do have allot of small files that I keep online. Perhaps it
would be best to back them up and just keep the current files instead
of all of them? PIO versus DMA mode? You lost me.

Graph pane? I hate to sound stupid but you have to bear with me some.
Where or what is the graph pane?

I think there may be some misunderstanding. I don’t have the option of
another computer. I said I may have another Seagate ST3160815A (160GB)
HD and the cleaned Western Digital original (40GB) HD. As replacements
if my HD is gone.

@ David H Lipman -

I don’t have the ability to put the drive on another computer. However
I will run the Sea Tools long tests again and will also try letting it
do Chkdsk again at least for 2-3 hours and maybe we’ll get lucky.

I never thought there was a need to run Malwarebytes anti malware (MBAM) in the first
place. However it is GOOD to have an with it updated and periodically perform a quick
scan. It will coexist with SpyBot S&D and Avira. { You may not know this but I am a
former Malwarebytes, Malaware Resercher, employee.}

Placing the affected hard disk on a surrogate computer is part of the process of
elimination. You whittle around the edges of a problem and eliminate certain factors so
one can come to a more definitive conclusion.
 
P

Paul

Navyguy said:
I ran a full scan with Malware bytes Anti-malware which completed
successfully and found nothing.

In passing, will Malwarebytes Anti-Malware conflict with Spybot or
Spywareblaster or Avira or cause the computer to slow down? Should I
leave it on the computer? Is there a danger of having too much?

@ J.P. Giiliver (John) - I forgot that my vintage of computer it
fractures HD’s above a certain size into two partitions. My 160 GB HD
after formatting and partitioning fractured into two partitions of 127
GB and 33 GB. It seems they didn’t envisage the computer needing more
memory when they wee made and so when it reaches it maximum it
fractures the drive into (2) partitions by default. I’ve never used
the smaller partition before but perhaps instead of adding another
drive I should use that instead and save the 40GB HD as a backup.

@Paul – I do have allot of small files that I keep online. Perhaps it
would be best to back them up and just keep the current files instead
of all of them? PIO versus DMA mode? You lost me.

Graph pane? I hate to sound stupid but you have to bear with me some.
Where or what is the graph pane?

I think there may be some misunderstanding. I don’t have the option of
another computer. I said I may have another Seagate ST3160815A (160GB)
HD and the cleaned Western Digital original (40GB) HD. As replacements
if my HD is gone.

@ David H Lipman -

I don’t have the ability to put the drive on another computer. However
I will run the Sea Tools long tests again and will also try letting it
do Chkdsk again at least for 2-3 hours and maybe we’ll get lucky.


Thanks,
Robert

One part of your response concerns me. You say

"My 160 GB HD after formatting and partitioning fractured into
two partitions of 127 GB and 33 GB."

Are you using the 33GB part, the part near the end of the disk ?
I wouldn't do that. If the OS really created that split in the
first place, it shouldn't allow you access to the 33GB part.
You should leave that space Unallocated.

So some questions for you would be:

1) Does the 33GB section have a partition present (NTFS or FAT32 etc) ?

2) Have you been writing files to the 33GB part, when your setup doesn't
guarantee safe access above 128 or 137GB ?

Paul
 
N

Navyguy

In message <[email protected]>, Paul <[email protected]>
writes:
[]>Using the Performance plugin, you might also check for abnormal
performance, such as a too-low command rate to the disk. If the
disk had some bad blocks on it, the disk may wait 15 seconds while
attempting to read a block, which can slow down the apparent performance..
That would show up, if you were running the CHKDSK option that
causes all sectors to be read.
When you right click in the graph pane, and "Add Counter", there is a
section for disk counters in there. One of them is "Disk read bytes/sec",
while another might be "Disk reads/sec" and that is a measure of the

[]
Surely, if he's run Seagate's own SeaTools, he's established that there
is nothing wrong with the hardware necessitating any of the above?

Navyguy: probably _is_ worth taking all those small files you no longer
use off the disc (to CD/DVD? - or just to that other partition you said
you've never used), and (since the hardware is OK) running a defrag
after the removal. That _might_ make chkdsk run faster.

Others: what is chkdsk actually doing during the three passes?

General: if not already tried, it might be worth running chkdsk in safe
mode: I was just wondering if in normal mode something is repeatedly
making it restart. (If it goes to chkdsk before you get to the point
where you can select safe mode, abort it, go to safe mode, and start
chkdsk manually. If this idea is flawed - which it may be - someone else
please say.)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf

"Software is a gas. It will expand to fill whatever container it is placed in."
-- R. Martell, 1999

I ran and passed the Sea Tools Long DST (Long Self Drive Test) and
Long Generic Test. Then I let Chkdsk run again last night for approx.
6 hours with the same results as if its in a loop. I did a backup of
all my files then went in and deleted many of those files keeping only
the most current. It ‘seems’ that my computer is noticeably faster so
will try Chkdsk again.


@ David H. Lipman - I wish I had another computer for diagnosis etc,
but alas I don't. Whenever I upgrade I'll keep this for that purpose.

@ Paul No I'm not using any of the 33GB partition and I've left it
unallocated.


Thanks,
Robert
 
D

David H. Lipman

From: "J. P. Gilliver (John) said:
One part of your response concerns me. You say

"My 160 GB HD after formatting and partitioning fractured into
two partitions of 127 GB and 33 GB."

Are you using the 33GB part, the part near the end of the disk ?
I wouldn't do that. If the OS really created that split in the
first place, it shouldn't allow you access to the 33GB part.

Around the time 160G drives were common, there was a barrier around 120/137 GB (I think
the 137 was due to the difference between 1k and 1K, scaled up) which some BIOSes
couldn't go past. Some drives around that time had an extra link on the back, which
allowed those drives to work with such BIOSes, simply by locking out the top bit (i. e.
they became a 137G drive). I'm not sure what happened if you used such a drive on such a
BIOS _without_ putting the link in the right position, but I presume it doesn't work
properly.
[][/QUOTE]

"Some drives around that time had an extra link on the back"

You mean there was a jumper that needed to be physically set for >137GB drive translation
on some drives.
 
P

Paul

J. P. Gilliver (John) said:
One part of your response concerns me. You say

"My 160 GB HD after formatting and partitioning fractured into
two partitions of 127 GB and 33 GB."

Are you using the 33GB part, the part near the end of the disk ?
I wouldn't do that. If the OS really created that split in the
first place, it shouldn't allow you access to the 33GB part.

Around the time 160G drives were common, there was a barrier around
120/137 GB (I think the 137 was due to the difference between 1k and 1K,
scaled up) which some BIOSes couldn't go past. Some drives around that
time had an extra link on the back, which allowed those drives to work
with such BIOSes, simply by locking out the top bit (i. e. they became a
137G drive). I'm not sure what happened if you used such a drive on such
a BIOS _without_ putting the link in the right position, but I presume
it doesn't work properly.
[][/QUOTE]

There was no "clip" jumper for 128/137.

http://www.tldp.org/HOWTO/Large-Disk-HOWTO-11.html

"11.4 Jumpers that clip total capacity

Clip to 2.1 GB

Clip to 33 GB

With an old BIOS and a disk larger than 33.8 GB, the BIOS may hang,
and in such cases booting may be impossible, even when the disk is
removed from the CMOS settings.
"

"For drives larger than 137 GB also READ NATIVE MAX ADDRESS returns
a conventional value, namely 0xfffffff, corresponding to 137 GB.

Here READ NATIVE MAX ADDRESS EXT and SET MAX ADDRESS EXT
(using 48-bit addressing) are required.
"

So clipping to 2.1 or 33GB, has something to do with getting past
a BIOS bug. While 137GB is a boundary caused by not knowing about the
extensions that handle above 137GB (double pumped register cycles).
The double pumping is described here.

http://www.t10.org/t13/technical/e00101r6.pdf

There is one utility available, for checking whether a computer
can support above 137GB, but it costs money, and the disk manufacturers
should have provided it instead (as a "disk advisor" of sorts). It's
pathetic, that the only piece of software that claims to be able
to report such, costs money.

A guide to the 137GB issue can be found archived here. So this
was the wisdom at the time. Compared to this guide, I found
via a couple experiments, that my OS installer disks handled
the situation well. My Win2K without SP, wouldn't go past 137,
while my Win2K SP4, would. So at least at install time, it
seemed to work without causing grief.

http://web.archive.org/web/20070121085230/http://www.seagate.com/support/kb/disc/tp/137gb.pdf

What doesn't work well, is dual booting, with one OS that supports
137, mixed with a second OS that is <137. Then, you can suffer
corruption. I tested that on purpose, to see if I could break it,
and I did. There was one particular configuration that broke
(big partition, that spans the 137GB boundary). And something like
that might happen, if the >137 OS gets to choose the disk layout.

Paul
 
N

Navyguy

From: "J. P. Gilliver (John)" <[email protected]>
Around the time 160G drives were common, there was a barrier around 120/137 GB (I think
the 137 was due to the difference between 1k and 1K, scaled up) which some BIOSes
couldn't go past. Some drives around that time had an extra link on theback, which
allowed those drives to work with such BIOSes, simply by locking out the top bit (i. e.
they became a 137G drive). I'm not sure what happened if you used such a drive on such a
BIOS _without_ putting the link in the right position, but I presume itdoesn't work
properly.
[]

"Some drives around that time had an extra link on the back"

You mean there was a jumper that needed to be physically set for >137GB drive translation
on some drives.

--
Dave
Multi-AV Scanning Tool -http://multi-av.thespykiller.co.ukhttp://www.pctipp.ch/downloads/dl/35905.asp- Hide quoted text -

- Show quoted text -[/QUOTE]





I tried running defrag but it cam back with:

Disk Defragmenter has detected that Chkdsk is scheduled to run on
the volume: (C:). Please run Chkdsk /f.

Chkdsk is not completing 1 of 3

No, not using any of the 33 GB partition
Does the 33GB section have a partition present (NTFS or FAT32 etc) ?
The partition is 21.06 GB Unallotted. The C: Drive is 127.99 GB NTFS
Healthy (System)
2) Have you been writing files to the 33GB part, when your setup
doesn't
guarantee safe access above 128 or 137GB ?
No I haven’t written anything to the 21.06GB partition.

Thanks,
Robert
 
P

Paul

Navyguy said:
From: "J. P. Gilliver (John)" <[email protected]>




[]
One part of your response concerns me. You say
"My 160 GB HD after formatting and partitioning fractured into
two partitions of 127 GB and 33 GB."
Are you using the 33GB part, the part near the end of the disk ?
I wouldn't do that. If the OS really created that split in the
first place, it shouldn't allow you access to the 33GB part.
Around the time 160G drives were common, there was a barrier around 120/137 GB (I think
the 137 was due to the difference between 1k and 1K, scaled up) which some BIOSes
couldn't go past. Some drives around that time had an extra link on the back, which
allowed those drives to work with such BIOSes, simply by locking out the top bit (i. e.
they became a 137G drive). I'm not sure what happened if you used such a drive on such a
BIOS _without_ putting the link in the right position, but I presume it doesn't work
properly.
[]
"Some drives around that time had an extra link on the back"

You mean there was a jumper that needed to be physically set for >137GB drive translation
on some drives.

--
Dave
Multi-AV Scanning Tool -http://multi-av.thespykiller.co.ukhttp://www.pctipp.ch/downloads/dl/35905.asp- Hide quoted text -

- Show quoted text -





I tried running defrag but it cam back with:

Disk Defragmenter has detected that Chkdsk is scheduled to run on
the volume: (C:). Please run Chkdsk /f.

Chkdsk is not completing 1 of 3

No, not using any of the 33 GB partition
Does the 33GB section have a partition present (NTFS or FAT32 etc) ?
The partition is 21.06 GB Unallotted. The C: Drive is 127.99 GB NTFS
Healthy (System)
2) Have you been writing files to the 33GB part, when your setup
doesn't
guarantee safe access above 128 or 137GB ?
No I haven’t written anything to the 21.06GB partition.

Thanks,
Robert

Have you tried running chkdsk /f from Safe Mode ?

Do you have a means of getting to the recovery console (basically, booting
to an MSDOS prompt). You could also try running chkdsk /f from there.
But if you do that, you need a means to determine which partition is which.
Virtually every Windows OS, comes up with a different drive letter order.
And the recovery console is no different.

As a test, this is what I tried.

1) Got the Windows 7 recovery CD I prepared a while back.
2) Booted it on this computer (WinXP desktop).
3) The Windows 7 recovery CD says "it can't find any Windows 7 installs
to log into", which is true. It then asks if you'd like to see
the recovery options. You select that option. One of the options
in the list, is "command prompt" and from there you can run CHKDSK.

(You can see the "command prompt" option here, when using a Windows 7 recovery disc...)

http://www.techfeb.com/wp-content/uploads/2011/06/windows-7-recovery-disc-1_thumb.png

If you had a real WinXP installer CD, booting that will get you to
a recovery console command prompt setup. If you have a real WinXP installer
CD, you can also install the recovery console as a "second OS", then select
it from the boot menu at boot time. But on pre-built computers,
you may be lacking such options, and not have a real installer CD to
work with.

And that's where other bootable options come into play. And finding
a Windows 7 recovery CD may be a bit easier than finding one for
WinXP.

*******

There was one little trick, when I tested that just now.

The drive letters were:

X: Used for the CDROM holding the Windows 7 recovery CD
C:, D:, E:, F:, G:, H:, I: All the partitions on my two hard drives.
E: in this environment, is the D: I normally see
when booted in WinXP.

Now, sitting in that command prompt window, you can change directory
by typing the drive letter. For example, I can do

E:
dir

and see a directory listing for the "fake E:". From that, I can tell it's
the D: partition I really wanted. Now the prompt on the screen says

E:>

which is the current working directory. If I type

E:> chkdsk /f e:

that won't work, because I'd "pointed" at E: in the command prompt.
First, I had to change letters, back to X: for the prompt. I type X:
like this...

X:

and the prompt changes to

X:>

and then I can successfully run chkdsk like this. By doing it this
way, E: is no longer busy...

X:> chkdsk /f e:

and it works. After it finished, I could select restart from the other window.
Typing "exit" in a command prompt window, is another way to end the session
in that window.

Perhaps you'll be able to get it to complete from there.

*******

If that fails, the other options are going to be more work and harder
to do. Since you have at least one Seagate disk, you could try transferring
all the files to another disk. *IF* this tool does file by file transfers
from one disk to the next, then it offers an opportunity to part ways
with the defective file system. You'd copy C: from one disk, and make
a new C: on the other disk. As long as the MBR, partition boot sectors,
and C: files were copied across, it would be an exact copy. But the tool
would format the target partition first, before copying the files, and it
is that step you'd hope would clean the file system. Doing that, will
result in WinXP being on a disk with a different physical serial number
and with a different volume ID value for the partition, and may trigger
Windows activation again. But it could be one way to clean up the mess.

DiscWizard on this page, will work if Seagate disks are present.

http://www.seagate.com/ww/v/index.j...toid=d9fd4a3cdde5c010VgnVCM100000dd04090aRCRD

It includes a user manual.

When installed in a working Windows environment, one of the options
is "media builder", which builds some kind of BartPE like boot disc.
You then burn a CD with that, and that is an option for booting a computer
that will no longer boot (or, copying an old data disk, to a new data disk,
without having a Windows OS present). the boot disc in that case, takes
the place of a working Windows.

As long as that environment can copy files, then you could try your hand
at moving C: from one disk to your spare one. As long as the spare
is big enough to handle everything. And naturally, if the target
somehow ends up bigger than 127 or whatever, you know there'd be trouble.
But there is no reason for that to happen.

But given how difficult this idea is, I'd stick with punting around chkdsk
for now at least.

*******

You're probably wondering "where can I find a Windows 7 disc to try this".

Well, the neosmart web site, used to have a couple .torrent links which
pointed at 200MB images of recovery CDs for Windows 7 (suitable for
doing command prompt work on a WinXP system, with some subtle differences).
The idea of using .torrent files, is neosmart was not offering the
200MB download from their own site, merely point to the distributted
torrent system as a source of the download file.

Microsoft sent the lawyers after them, so Neosmart took the .torrent links
off the web page. Now, neosmart offers to sell you a recovery CD, which isn't
what I would have expected as a response to the lawyers.

Instead, you can also use an installer DVD to do the same thing. This link
was posted a while back, and it points at DigitalRiver as a source of
Windows 7 images. I tested this, and managed to get a >3GB file from one
of these links.

http://techpp.com/2009/11/11/download-windows-7-iso-official-direct-download-links/

I'm going to shut down now, and do some testing, and see if I can get a
recovery console prompt from that. The thing is, you can download a DVD
like that all you want, and without a license key, its useless. So it's
not like the >3GB thing has any value as such. But it should function
as a means of getting a recovery prompt, as a way to run CHKDSK, if say,
Safe Mode didn't work in WinXP to get the job done. I have to reconfigure
some hardware, which is why I have to shut down now.

Paul
 
P

Paul

Paul said:
Instead, you can also use an installer DVD to do the same thing. This link
was posted a while back, and it points at DigitalRiver as a source of
Windows 7 images. I tested this, and managed to get a >3GB file from one
of these links.

http://techpp.com/2009/11/11/download-windows-7-iso-official-direct-download-links/

I'm going to shut down now, and do some testing, and see if I can get a
recovery console prompt from that. The thing is, you can download a DVD
like that all you want, and without a license key, its useless. So it's
not like the >3GB thing has any value as such. But it should function
as a means of getting a recovery prompt, as a way to run CHKDSK, if say,
Safe Mode didn't work in WinXP to get the job done. I have to reconfigure
some hardware, which is why I have to shut down now.

Paul

OK, I finished testing that. I burned a Windows 7 SP1 64 bit retail edition
to a rewritable DVD, and used that to boot my WinXP computer. When booted,
the DVD won't find any Windows 7 OSes to repair. You then click the
upper left button, to select "recovery tools..." and in the next menu,
that's where the "Command Prompt" option will be.

This time, when I got the "X:>" type prompt, the partition I tested
before had become G: (instead of the D: it is under WinXP). So at
the prompt I typed

X:> chkdsk /f g:

and it ran to completion.

When deciding whether to download a 32 bit or 64 bit installer DVD
(you're not installing from it, just booting the recovery console),
you'd consider whether the computer can even run 64 bit instructions.
Mine has a Core 2 processor (not the newest), and it supports 32 bit
and 64 bit instructions. Some of the older P4 processors, are 32 bit only.
So you might want to download a 3.2GB copy of a 32 bit disc
and use that, if you can't find anything else to use.

And that's only necessary, if you run out of other ideas to get
a command prompt to run chkdsk from. Like finding a copy of the
200MB CD version which does the same thing.

The partition I selected for the above test, was selected based
on size. That partition (g: in the above example) is only a
couple gigabytes, so CHKDSK doesn't take long to run. I just
needed it to run long enough, to prove the chkdsk.exe on the
64 bit disc, was going to run for me or not. It might not have
done so, if I tried testing that disc on a 32 bit only computer.

Paul
 
P

Paul

J. P. Gilliver (John) said:
There was no "clip" jumper for 128/137.

http://www.tldp.org/HOWTO/Large-Disk-HOWTO-11.html

"11.4 Jumpers that clip total capacity

Clip to 2.1 GB

Clip to 33 GB

With an old BIOS and a disk larger than 33.8 GB, the BIOS may hang,
and in such cases booting may be impossible, even when the disk is
removed from the CMOS settings.
"

"For drives larger than 137 GB also READ NATIVE MAX ADDRESS returns
a conventional value, namely 0xfffffff, corresponding to 137 GB.

Here READ NATIVE MAX ADDRESS EXT and SET MAX ADDRESS EXT
(using 48-bit addressing) are required.
"

So clipping to 2.1 or 33GB, has something to do with getting past
a BIOS bug. While 137GB is a boundary caused by not knowing about the
extensions that handle above 137GB (double pumped register cycles).
[]
Whatever the reason - BIOS or OS - I definitely remember seeing such
jumpers, on drives just over the 137 size (such as 160G). I don't
remember seeing them on anything bigger (such as 220G).[/QUOTE]

Maybe it was something to remove the _EXT command set from the drive ?

I've never seen a reference to such a thing. It's not like it's impossible
or anything, because some of the jumper definitions on the back of
hard drives, are buried in the "Technical Specification" document
from the disk manufacturer. The jumper setting shown on the
label, are usually a subset of all possible jumper combos, and
don't admit to some special options. It can take a lot of digging,
to get a complete breakdown on what is possible. They no longer
put the 100+ page PDF description of the drive, within easy
download reach. Just the fluffy two page "specs", which in
some cases now, don't even include +5V/+12V power consumption numbers.

Paul
 
N

Navyguy

Navyguy said:
From: "J. P. Gilliver (John)" <[email protected]>
[]
One part of your response concerns me. You say
  "My 160 GB HD after formatting and partitioning fractured into
   two partitions of 127 GB and 33 GB."
Are you using the 33GB part, the part near the end of the disk ?
I wouldn't do that. If the OS really created that split in the
first place, it shouldn't allow you access to the 33GB part.
Around the time 160G drives were common, there was a barrier around 120/137 GB (I think
the 137 was due to the difference between 1k and 1K, scaled up) whichsome BIOSes
couldn't go past. Some drives around that time had an extra link on the back, which
allowed those drives to work with such BIOSes, simply by locking out the top bit (i. e.
they became a 137G drive). I'm not sure what happened if you used such a drive on such a
BIOS _without_ putting the link in the right position, but I presume it doesn't work
properly.
[]
"Some drives around that time had an extra link on the back"
You mean there was a jumper that needed to be physically set for >137GB drive translation
on some drives.
I tried running defrag but it cam back with:
Disk Defragmenter  has detected that Chkdsk  is scheduled to run on
the volume: (C:). Please run Chkdsk /f.
Chkdsk is not completing 1 of 3
No, not using any of the 33 GB partition
Does the 33GB section have a partition present (NTFS or FAT32 etc) ?
The partition is 21.06 GB Unallotted. The C: Drive is 127.99 GB NTFS
Healthy (System)
2) Have you been writing files to the 33GB part, when your setup
doesn't
    guarantee safe access above 128 or 137GB ?
No I haven’t written anything to the 21.06GB partition.
Thanks,
Robert

Have you tried running chkdsk /f from Safe Mode ?

Do you have a means of getting to the recovery console (basically, booting
to an MSDOS prompt). You could also try running chkdsk /f from there.
But if you do that, you need a means to determine which partition is which.
Virtually every Windows OS, comes up with a different drive letter order.
And the recovery console is no different.

As a test, this is what I tried.

1) Got the Windows 7 recovery CD I prepared a while back.
2) Booted it on this computer (WinXP desktop).
3) The Windows 7 recovery CD says "it can't find any Windows 7 installs
    to log into", which is true. It then asks if you'd like to see
    the recovery options. You select that option. One of the options
    in the list, is "command prompt" and from there you can run CHKDSK.

(You can see the "command prompt" option here, when using a Windows 7 recovery disc...)

http://www.techfeb.com/wp-content/uploads/2011/06/windows-7-recovery-...

If you had a real WinXP installer CD, booting that will get you to
a recovery console command prompt setup. If you have a real WinXP installer
CD, you can also install the recovery console as a "second OS", then select
it from the boot menu at boot time. But on pre-built computers,
you may be lacking such options, and not have a real installer CD to
work with.

And that's where other bootable options come into play. And finding
a Windows 7 recovery CD may be a bit easier than finding one for
WinXP.

*******

There was one little trick, when I tested that just now.

The drive letters were:

X:                           Used for the CDROMholding the Windows 7 recovery CD
C:, D:, E:, F:, G:, H:, I:   All the partitions on my two hard drives.
                              E: in this environment, is the D: I normally see
                              when booted in WinXP.

Now, sitting in that command prompt window, you can change directory
by typing the drive letter. For example, I can do

    E:
    dir

and see a directory listing for the "fake E:". From that, I can tell it's
the D: partition I really wanted. Now the prompt on the screen says

    E:>

which is the current working directory. If I type

    E:>  chkdsk /f e:

that won't work, because I'd "pointed" at E: in the command prompt.
First, I had to change letters, back to X: for the prompt. I type X:
like this...

    X:

and the prompt changes to

    X:>

and then I can successfully run chkdsk like this. By doing it this
way, E: is no longer busy...

    X:>  chkdsk /f e:

and it works. After it finished, I could select restart from the other window.
Typing "exit" in a command prompt window, is another way to end the session
in that window.

Perhaps you'll be able to get it to complete from there.

*******

If that fails, the other options are going to be more work and harder
to do. Since you have at least one Seagate disk, you could try transferring
all the files to another disk. *IF* this tool does file by file transfers
from one disk to the next, then it offers an opportunity to part ways
with the defective file system. You'd copy C: from one disk, and make
a new C: on the other disk. As long as the MBR, partition boot sectors,
and C: files were copied across, it would be an exact copy. But the tool
would format the target partition first, before copying the files, and it
is that step you'd hope would clean the file system. Doing that, will
result in WinXP being on a disk with a different physical serial number
and with a different volume ID value for the partition, and may trigger
Windows activation again. But it could be one way to clean up the mess.

DiscWizard on this page, will work if Seagate disks are present.

http://www.seagate.com/ww/v/index.jsp?locale=en-US&name=DiscWizard&vg....

It includes a user manual.

When installed in a working Windows environment, one of the options
is "media builder", which builds some kind of BartPE like boot disc.
You then burn a CD with that, and that is an option for booting a computer
that will no longer boot (or, copying an old data disk, to a new data disk,
without having a Windows OS present). the boot disc in that case, takes
the place of a working Windows.

As long as that environment can copy files, then you could try your hand
at moving C: from one disk to your spare one. As long as the spare
is big enough to handle everything. And naturally, if the target
somehow ends up bigger than 127 or whatever, you know there'd be trouble.
But there is no reason for that to happen.

But given how difficult this idea is, I'd stick with punting around chkdsk
for now at least.

*******

You're probably wondering "where can I find a Windows 7 disc to try this"..

Well, the neosmart web site, used to have a couple .torrent links which
pointed at 200MB images of recovery CDs for Windows 7 (suitable for
doing command prompt work on a WinXP system, with some subtle differences).
The idea of using .torrent files, is neosmart was not offering the
200MB download from their own site, merely point to the distributted
torrent system as a source of the download file.

Microsoft sent the lawyers after them, so Neosmart took the .torrent links
off the web page. Now, neosmart offers to sell you a recovery CD, which isn't
what I would have expected as a response to the lawyers.

Instead, you can also use an installer DVD to do the same thing. This link
was posted a while back, and it points at DigitalRiver as a source of
Windows 7 images. I tested this, and managed to get a >3GB file from one
of these links.

http://techpp.com/2009/11/11/download-windows-7-iso-official-direct-d...

I'm going to shut down now, and do some testing, and see if I can get a
recovery console prompt from that. The thing is, you can download a DVD
like that all you want, and without a license key, its useless. So it's
not like the >3GB thing has any value as such. But it should function
as a means of getting a recovery prompt, as a way to run CHKDSK, if say,
Safe Mode didn't work in WinXP to get the job done. I have to reconfigure
some hardware, which is why I have to shut down now.

    Paul- Hide quoted text -

- Show quoted text -

I’m sorry I haven’t responded of late, I’m also dealing with car
problems and plumbing problems. The instructions given seem very
involved and would take some time from me to do them.
However, it finally let me go into Safe Mode and I selected to start
up with Safe Mode with Command prompt but after hitting enter it just
hung there. Later I came back and it was at the normal logon screen.
Tonight I logged on and pressed the f8 key to try again and this time
it went to the logon screen with no Chkdsk. So I decided to do a test
and restarted the computer and it came up normally with no Chkdsk!
Thoughts?
Robert
 
P

Paul

Navyguy said:
I’m sorry I haven’t responded of late, I’m also dealing with car
problems and plumbing problems. The instructions given seem very
involved and would take some time from me to do them.
However, it finally let me go into Safe Mode and I selected to start
up with Safe Mode with Command prompt but after hitting enter it just
hung there. Later I came back and it was at the normal logon screen.
Tonight I logged on and pressed the f8 key to try again and this time
it went to the logon screen with no Chkdsk. So I decided to do a test
and restarted the computer and it came up normally with no Chkdsk!
Thoughts?
Robert

Count your blessings ? :)

All I can say is, I know how I'd fix it, but not everyone will choose
to do it that way. I'd copy the data off, reformat the partition,
and put the data back. But that's not everyone's cup of tea.
(I have enough spare disks, to do that safely. Backup copy plus transfer copy.)

The thing is, if you did nothing explicit to stop chkdsk from running,
what assurance do you have it won't come back in two days time, with
the same crap (chkdsk at boot) ?

If you'd managed to get chkdsk to run to completion on one of your
runs, it would be easier to understand why it has stopped. If you
did nothing to stop it (no registry change, no chkdsk to completion),
then there isn't an explanation for where it went. And no assurance
it won't be back.

I like to maintain my system here, such that I can go to properties, tools,
and select chkdsk on a partition, without being concerned it'll go off
into the woods. If I'm seeing signs of trouble, then I try to fix them,
rather than leaving the situation for some future catastrophe. You can
choose to ignore the underlying problem if you want, but maybe all it'll
take, is turning off the power too fast on the computer (another dirty
shutdown), to put you back in the same situation again (infinite duration
chkdsk).

One reason I can do a repair that way, is because I have a dual boot system,
and I boot Win2K when I want to fix my WinXP C: partition. That gives me
a lot of flexibility for this "copy and reformat" idea. If it's a partition
other than C:, then it's a lot easier to deal with a problem there. And that's
virtually all that the Win2K does on my system, is work as a "maintenance" OS
so I can fix stuff when needed. (I'd do it from Linux, but Linux doesn't
have every tool needed for Windows maintenance. There is no "fixboot".)

Paul
 
N

Navyguy

Count your blessings ? :)

All I can say is, I know how I'd fix it, but not everyone will choose
to do it that way. I'd copy the data off, reformat the partition,
and put the data back. But that's not everyone's cup of tea.
(I have enough spare disks, to do that safely. Backup copy plus transfer copy.)

The thing is, if you did nothing explicit to stop chkdsk from running,
what assurance do you have it won't come back in two days time, with
the same crap (chkdsk at boot) ?

If you'd managed to get chkdsk to run to completion on one of your
runs, it would be easier to understand why it has stopped. If you
did nothing to stop it (no registry change, no chkdsk to completion),
then there isn't an explanation for where it went. And no assurance
it won't be back.

I like to maintain my system here, such that I can go to properties, tools,
and select chkdsk on a partition, without being concerned it'll go off
into the woods. If I'm seeing signs of trouble, then I try to fix them,
rather than leaving the situation for some future catastrophe. You can
choose to ignore the underlying problem if you want, but maybe all it'll
take, is turning off the power too fast on the computer (another dirty
shutdown), to put you back in the same situation again (infinite duration
chkdsk).

One reason I can do a repair that way, is because I have a dual boot system,
and I boot Win2K when I want to fix my WinXP C: partition. That gives me
a lot of flexibility for this "copy and reformat" idea. If it's a partition
other than C:, then it's a lot easier to deal with a problem there. And that's
virtually all that the Win2K does on my system, is work as a "maintenance" OS
so I can fix stuff when needed. (I'd do it from Linux, but Linux doesn't
have every tool needed for Windows maintenance. There is no "fixboot".)

    Paul


I actually tend to agree although at this point I may elect to let run
for a bit and sort out my other problems and then come back to this.
Although as you say it may happen again, I just didn't know which
procedure to follow. I have backed everything up using Nero. About re-
formatting, I think its best to just reformat with the (1) partition
and let it fracture like it did before and leave the smaller partition
un-allocatd. Correct? If I have problems before or after Partitioning
I'll start another Thread.

Thanks to everyone for their good advice and help.

Thanks,
Robert
 
P

Paul

Navyguy said:
I actually tend to agree although at this point I may elect to let run
for a bit and sort out my other problems and then come back to this.
Although as you say it may happen again, I just didn't know which
procedure to follow. I have backed everything up using Nero. About re-
formatting, I think its best to just reformat with the (1) partition
and let it fracture like it did before and leave the smaller partition
un-allocatd. Correct? If I have problems before or after Partitioning
I'll start another Thread.

Thanks to everyone for their good advice and help.

Thanks,
Robert

You have an approx. 128GB partition that needs maintenance. I think you
had a 160GB spare disk. If the OS is enforcing a less than 48 bit LBA
rule, then if you were to create a partition on the 160GB drive, it will
be 128GB as well. It might not be exactly the same size, byte for byte, but
if you're doing file-by-file copying, that should be fine.

At the moment, the area up near the end of the disk (above 128GB), is pretty useless.
There may be ways to gain access to it, but is that space above 128GB
going to be of any use to you ? It's too small.

There are ways to fix that problem, and allow you to use more of the disk,
but the disadvantage occurs when you need to do maintenance later. Some
utilities are smart enough to recognize one of these are in place. But all it
takes is some piece of software that isn't aware, to make a mess. And that
is the reason I've never personally been interested in using stuff like
this.

http://en.wikipedia.org/wiki/Dynamic_Drive_Overlay

I think I still have one computer here, that's stuck at 128GB. But it
isn't one of my "everyday" computers. Web surfing on that thing is
so slow, it's not worth plugging in.

Right now, I'm wondering if some free version of Macrium Reflect might
be enough to clean up C:. I'm off to try some experiments... What
I don't know at the moment, is whether Macrium would be enough on its
own. There is a free version, a download from CNET, and the first job
will be to determine whether it's got some toolbar in it or not :-(
Some of these downloads, are packed with hacker style packers, and
it makes it hard for me to verify they're clean. And this one is
too big to pop up onto virustotal.com for a check. (I use virustotal
as much for the unpacking information, as I do for virus scans. It
helps tell me what tricks are being used. All half decent virus scanners
know all the packing tricks, but my tool of choice, 7-ZIP, isn't
very good at it.)

http://www.macrium.com/reflectfree.aspx

I'm not testing this on a live system, but using a virtual machine
for some measure of safety.

Paul
 
P

Paul

Paul said:
You have an approx. 128GB partition that needs maintenance. I think you
had a 160GB spare disk. If the OS is enforcing a less than 48 bit LBA
rule, then if you were to create a partition on the 160GB drive, it will
be 128GB as well. It might not be exactly the same size, byte for byte, but
if you're doing file-by-file copying, that should be fine.

At the moment, the area up near the end of the disk (above 128GB), is
pretty useless.
There may be ways to gain access to it, but is that space above 128GB
going to be of any use to you ? It's too small.

There are ways to fix that problem, and allow you to use more of the disk,
but the disadvantage occurs when you need to do maintenance later. Some
utilities are smart enough to recognize one of these are in place. But
all it
takes is some piece of software that isn't aware, to make a mess. And that
is the reason I've never personally been interested in using stuff like
this.

http://en.wikipedia.org/wiki/Dynamic_Drive_Overlay

I think I still have one computer here, that's stuck at 128GB. But it
isn't one of my "everyday" computers. Web surfing on that thing is
so slow, it's not worth plugging in.

Right now, I'm wondering if some free version of Macrium Reflect might
be enough to clean up C:. I'm off to try some experiments... What
I don't know at the moment, is whether Macrium would be enough on its
own. There is a free version, a download from CNET, and the first job
will be to determine whether it's got some toolbar in it or not :-(
Some of these downloads, are packed with hacker style packers, and
it makes it hard for me to verify they're clean. And this one is
too big to pop up onto virustotal.com for a check. (I use virustotal
as much for the unpacking information, as I do for virus scans. It
helps tell me what tricks are being used. All half decent virus scanners
know all the packing tricks, but my tool of choice, 7-ZIP, isn't
very good at it.)

http://www.macrium.com/reflectfree.aspx

I'm not testing this on a live system, but using a virtual machine
for some measure of safety.

Paul

OK, Macrium is no good for this job. It creates a VHD, an image
of your C:, warts and all. So it can't "launder" the problems
out of the file system. It'll carefully preserve all the problems
that are present, whatever they are.

I can see the possibilities of using BartPE for this kind of
repair work, and tossing a few utilities into PEBuilder, to
make a boot CD to work on the computer. But the thing is,
would you be happy building your own BartPE boot CD ?

Paul
 
P

Paul

Paul said:
OK, Macrium is no good for this job. It creates a VHD, an image
of your C:, warts and all. So it can't "launder" the problems
out of the file system. It'll carefully preserve all the problems
that are present, whatever they are.

I can see the possibilities of using BartPE for this kind of
repair work, and tossing a few utilities into PEBuilder, to
make a boot CD to work on the computer. But the thing is,
would you be happy building your own BartPE boot CD ?

Paul

If you have at least one Seagate hard drive, you can use Seagate
DiscWizard. That is actually a copy of Acronis True Image Home.

The manual for DiscWizard is here. Go to page 47.

http://www.seagate.com/support/discwizard/dw_ug.en.pdf

"Using the "as is" method Seagate DiscWizard transfers unsupported
and damaged file systems."

That implies, if you were to "clone" a disk (your suspicious disk to
your spare disk), you would *not* want the "as is" option, because it
would not result in anything being repaired or cleaned. If you use the
Proportional or Manual options, that sounds like it uses a file by file
approach. And that might afford an opportunity to clean up the file system
during the transfer.

What you'd do is:

C: --> Spare disk, change the size a little bit

Spare disk --> C: You could use "as is" here if you wanted, because
repairing your NTFS should have happened in the
first step.

I haven't tested this yet, and it'll take me a while to get set up.
I don't have enough disk ports on my current computer, to make this
easy.

What I have tested to date:

1) Installed the DiscWizard program.
2) When it said to reboot, I did not bother.
3) Instead, go to start menu, and run Seagate/DiscWizard.
Look for a Media Builder option. This will create an ISO9660 file.
You have to assign a file name to the output file, before it will save it.
I chose "acronis.iso" as the file name. The file size was 64,159,744 bytes.
4) Then, I went back to Add/Remove Programs and removed the DiscWizard install.
I did that, because I never expect to be running it, while Windows is running.
I will always be running it from a CD instead.
5) Using your favorite burning application, burn that file and make a boot CD.
You could use Nero or the free Imgburn to do that.

I used a virtual machine, to test that the resulting CD disc, will boot. And
it did. But my virtual machine has no Seagate disks, and the software does
a check that at least one of the disks is Seagate branded. So the software
stops at that point. (Note that, at one time Western Digital offered exactly
the same software, except it looks for a Western Digital branded drive.
So if you have a different brand of hard drive, there may still be software
to do the same thing. Or, you could always buy Acronis True Image Home or
equivalent, as a third option.)

So at the moment, I haven't had a chance to do a "live" transfer from
one disk to the other. To test that here, I have to use "real" disks
and not work in my virtualpc environment. There is a chance, that using
that software to copy C: over, then copy it back, will clean up the
file system (because, on the way back, it'll need to make a new file
system). At least, that's my hypothesis.

Paul
 
P

Paul

Paul said:
If you have at least one Seagate hard drive, you can use Seagate
DiscWizard. That is actually a copy of Acronis True Image Home.

The manual for DiscWizard is here. Go to page 47.

http://www.seagate.com/support/discwizard/dw_ug.en.pdf

"Using the "as is" method Seagate DiscWizard transfers unsupported
and damaged file systems."

That implies, if you were to "clone" a disk (your suspicious disk to
your spare disk), you would *not* want the "as is" option, because it
would not result in anything being repaired or cleaned. If you use the
Proportional or Manual options, that sounds like it uses a file by file
approach. And that might afford an opportunity to clean up the file system
during the transfer.

What you'd do is:

C: --> Spare disk, change the size a little bit

Spare disk --> C: You could use "as is" here if you wanted, because
repairing your NTFS should have happened in the
first step.

I haven't tested this yet, and it'll take me a while to get set up.
I don't have enough disk ports on my current computer, to make this
easy.

What I have tested to date:

1) Installed the DiscWizard program.
2) When it said to reboot, I did not bother.
3) Instead, go to start menu, and run Seagate/DiscWizard.
Look for a Media Builder option. This will create an ISO9660 file.
You have to assign a file name to the output file, before it will
save it.
I chose "acronis.iso" as the file name. The file size was 64,159,744
bytes.
4) Then, I went back to Add/Remove Programs and removed the DiscWizard
install.
I did that, because I never expect to be running it, while Windows is
running.
I will always be running it from a CD instead.
5) Using your favorite burning application, burn that file and make a
boot CD.
You could use Nero or the free Imgburn to do that.

I used a virtual machine, to test that the resulting CD disc, will boot.
And
it did. But my virtual machine has no Seagate disks, and the software does
a check that at least one of the disks is Seagate branded. So the software
stops at that point. (Note that, at one time Western Digital offered
exactly
the same software, except it looks for a Western Digital branded drive.
So if you have a different brand of hard drive, there may still be software
to do the same thing. Or, you could always buy Acronis True Image Home or
equivalent, as a third option.)

So at the moment, I haven't had a chance to do a "live" transfer from
one disk to the other. To test that here, I have to use "real" disks
and not work in my virtualpc environment. There is a chance, that using
that software to copy C: over, then copy it back, will clean up the
file system (because, on the way back, it'll need to make a new file
system). At least, that's my hypothesis.

Paul

OK, just finished the Acronis True Image Home test, and it
left me less than satisfied.

I laid a trap for it, in the sense that, for my test case, I started
with a source disk which had a single FAT32 partition. Then, I used the
"convert" utility in Windows, to convert the partition from FAT32 to NTFS.
One of the peculiarities of such a conversion, is the cluster size ends
up being 512 bytes instead of 4K or larger.

I did the conversion, and verified the cluster size on the source was 512 bytes.

Then, I used the Acronis boot disc, to start a "clone" session. I cloned
the freshly converted partition from one 80GB disk to the second 80GB disk.
In the process of cloning, I selected "manual" option, then specified that
the destination partition be slightly smaller. This was on the theory,
that the tool would use file by file copy, would freshly format the destination
partition, and that would cause a destination cluster size of 4K or larger.
(The format operation likely wouldn't pick 512 bytes on its own.)

When the operation was finished, I booted back into Windows to check the
cluster size. And it was reported as 512 bytes on both the source and
the destination disk. Both disk partitions had the same name. Both disk
partitions had the same volumeid. That "hints" to me, that they're not
doing an old fashioned file-by-file copy. I didn't get the kind
of proof I wanted - it may actually be doing the right thing,
but the test didn't give the right kind of hints. Another
hint I use, is the way the disk lights flash, and the flashing
pattern wasn't "file-by-file" like either.

The only other option I know of now, is the "Robocopy recipe" I've been
using for a while. Robocopy is a file copying utility from Microsoft.
So I know it won't cheat, because all it knows is how to do file-by-file.

The trick then, since you're in a single OS situation, is finding a way to
boot and run that. You can't destroy C: while you're running from it, which
is why some kind of boot CD is needed. Perhaps robocopy can be run from
the recovery console, so I suppose that is an option. That can be run from
a real Windows installer CD. But if you have a Dell, you might not have
a CD offering that as an option.

I tried BartPE for the first time, and it indeed ran. So not a problem there.
But it has similar dependencies. It needs an i386 directory, to use as a
source of files to build a boot disk. It's unlikely that a Dell/HP/Acer
has the necessary directory and files. You also have to master the
"plugin" concept, and I haven't really tried adding my own custom
plugins yet. Since the programs I'd want to add, are for the most part
command line programs, that probably won't be a big deal to do. You use
PEBuilder application from the BartPE package, to take all the files and
plugins and build an ISO9660 file. Then, you burn that to make a self-contained
boot environment.

One thing I haven't figured out, is how I'd get a "fixboot" function
into BartPE. "fixboot" doesn't appear to exist as a separate .exe file.
There are ways to do it, but I don't know if I'm that comfortable with
some of them.

So while BartPE may make a platform suitable for the work, I'm not
positive at this point, that I have all the ingredients necessary
to do the "NTFS laundry" function I'm trying to set up.

Maybe what I need, is a really old backup and restore utility, from
before VSS and VHD appeared on the scene... Hmmm. I wonder if
ntbackup would work ? Off for another test...

Paul
 
P

Paul

Paul said:
So while BartPE may make a platform suitable for the work, I'm not
positive at this point, that I have all the ingredients necessary
to do the "NTFS laundry" function I'm trying to set up.

Maybe what I need, is a really old backup and restore utility, from
before VSS and VHD appeared on the scene... Hmmm. I wonder if
ntbackup would work ? Off for another test...

Paul

ntbackup was a bust, because it didn't handle "busy" files. And when
I checked the log to see which ones it didn't copy, they didn't look
dangerous (probably wouldn't break anything), but this makes it
too sloppy a method to give to somebody else. I certainly wouldn't
use this, knowing I have other methods available.

What I'm looking for here, is a recipe without a lot of loose ends.
I'm getting a little closer, but it's not looking like it's going
to be that easy.

I've been experimenting with driveimage_xml, which is a free package.
I downloaded the BartPE plugin version, and loaded that into the
plugins directory. Initial testing is looking positive, because
by using BartPE, there is no concern about busy files. (When BartPE
boots, the regular Windows isn't running, which is a good environment
for backups.) And when I looked in the .xml file the program outputs,
it makes mention of a bootsector, so it's possible it is properly
handling the partition boot sector. I can't be 100% sure yet, but
it's looking a bit better than the other methods I tried today.

http://www.runtime.org/peb.htm (BartPE Plugins page, with DriveImageXML)
http://www.runtime.org/driveimage_xml.cab (the file to download, and extract to make
a folder to dump in the BartPE plugin folder)

http://www.runtime.org/driveimage-xml.htm (What the dialog box looks like
while it is running)

http://www.nu2.nu/pebuilder/ (Bart downloads, near the bottom)

The unfortunate part, is I'm not sure BartPE is going to help
you, since it needs the i386 folder on a real WinXP installer
CD. If you have a Dell/HP/Acer without real installer CD, I don't
know if you can build a BartPE with PEbuilder without it.

Bart builds a boot disc, using install CD files. If there was an
i386 folder with ~5000 files on C:, then that might be a candidate.
There is a folder like that on a real installer CD. But on a
Dell/HP/Acer, it might not work. (A loose end...)

Another critical part, is you need a tool to "format" the original
suspect disk, while in BartPE, so DriveImageXML can copy back
the backup. If the original partition was NTFS, the reformatting
process would also be making an NTFS partition.

The recipe is looking like it'll be similar to this:

BartPE_with_DriveImageXML Copy C: to the spare drive
(I used two 80GB drives for my experiment)

Start a command prompt
"net start dmserver"
"net start dmadmin"
"diskpart"

<insert recipe to format C: and make sure it is marked "active".
Active means the boot flag byte for the partition is 0x80.
I'll work on the recipe tomorrow>

Now C: has a fresh clean NTFS file system and is ready to
have the files copied back.

BartPE_with_DriveImageXML Copy spare drive back to C:

The DriveImageXML information, hints that the only thing needed,
is to make sure the active flag is set. Implying it handles
"fixboot" by using the info it saved during the backup. At
least, that's how it looks right now. I have to finish the
experiment tomorrow.

Paul
 
P

Patok

Paul said:
ntbackup was a bust, because it didn't handle "busy" files. And when
I checked the log to see which ones it didn't copy, they didn't look
dangerous (probably wouldn't break anything), but this makes it
too sloppy a method to give to somebody else. I certainly wouldn't
use this, knowing I have other methods available.


Paul, what exactly are you trying to do? I didn't pay close
attention. If it is to do a file-level backup and restore onto a fresh
formatted disk, it seems that the Paragon free backup does that. Since
one of the backup options is to make a sector-level backup, it implies
that the normal modus operandi is to make a file-level one. And indeed,
you can tell it to skip pagefile.sys etc. Have you tried Paragon?
 
P

Paul

Patok said:
Paul, what exactly are you trying to do? I didn't pay close attention.
If it is to do a file-level backup and restore onto a fresh formatted
disk, it seems that the Paragon free backup does that. Since one of the
backup options is to make a sector-level backup, it implies that the
normal modus operandi is to make a file-level one. And indeed, you can
tell it to skip pagefile.sys etc. Have you tried Paragon?

I'm trying to do a file level backup, with the idea that a user
could move their C: contents to a backup disk, reformat C:,
then move the files back. I already have a nice recipe for this,
but it uses my dual boot OS setup (boot alternate OS, to do repairs).

The components that need to be repaired when you do that include:

1) Partition Boot Sector. Wiped on a format. The vital information
in the partition, such as cluster size or the like, is established by
the format operation. But the boot code is wiped. Even though the
active flag is set on the partition, the formatter doesn't care.
2) VolumeID (stored around sector 62 or so, in the head of the C: partition).
3) (DiskID in MBR is untouched)
4) (Active flag for C: should be untouched)

The VolumeID may fit into activation, so it's not that big a
deal. It won't prevent booting. I treat it as a "finishing touch".
There are three serial numbers, the hardware disk serial number,
the DiskID in the MBR (written when the MBR is first installed, and
probably doesn't change unless there is a collision), and the
VolumeID aka VSN stored in each partition. The command "vol c:"
for example, is supposed to report the VSN. The article on activation,
makes claims that some part of those numbers, fits into whether
re-activation is required.

The only utility I know of, for directly repairing the partition
boot sector, is running from a recovery console and doing "fixboot c:"
or equivalent. There is one utility that claims to be able to
"build a new boot sector", but I can't find the kind of detail
that would make me happy.

As for grabbing utilities, like freebies, I have a number
of arbitrary criteria when selecting them. So far, DriveImageXML
doesn't appear to be overstepping any boundaries, and it just
might be able to put the partition boot sector back. That's what
I'm about to test shortly.

What I've been trying to figure out right now, is how to add
Sysinternals VolumeID.exe to BartPE, so I can correct the VSN
after the partition is formatted. I plan to use diskpart to
format the old C:, and lay down a fresh NTFS on it.

list disk
select disk 0
list partition
select partition 1
detail partition (verify - active flag should be set on C:)
format fs=ntfs label="WINXP" quick
detail partition
exit

I don't see a reason to blow away C: and start over again.
The "format" should erase the header of the C: storage
space, losing the partition boot sector, and assigning a new
random volumeid aka VSN.

I don't know if the "drive letter" in BartPE can be used
in the Sysinternals volumeid command or not. The drive letter
could be assigned in detection order, in which case it might be

volumeid h: ABCD-1234 (ABCD-1234 is the value from the vol C:
command, run before starting this exercise)

Anyway, that's what I'm playing with. Trying to come up with a
single CD and operating environment, that is easy to put together,
to move a non-busy C: to another disk, and then back again after
reformatting. I've got BartPE working, and the available
DriveImageXML plugin worked fine. My backup of C: is sitting
on the spare disk, and that's what I plan to restore from.

Paul
 
N

Navyguy

You have an approx. 128GB partition that needs maintenance. I think you
had a 160GB spare disk. If the OS is enforcing a less than 48 bit LBA
rule, then if you were to create a partition on the 160GB drive, it will
be 128GB as well. It might not be exactly the same size, byte for byte, but
if you're doing file-by-file copying, that should be fine.

At the moment, the area up near the end of the disk (above 128GB), is pretty useless.
There may be ways to gain access to it, but is that space above 128GB
going to be of any use to you ? It's too small.

There are ways to fix that problem, and allow you to use more of the disk,
but the disadvantage occurs when you need to do maintenance later. Some
utilities are smart enough to recognize one of these are in place. But all it
takes is some piece of software that isn't aware, to make a mess. And that
is the reason I've never personally been interested in using stuff like
this.

http://en.wikipedia.org/wiki/Dynamic_Drive_Overlay

I think I still have one computer here, that's stuck at 128GB. But it
isn't one of my "everyday" computers. Web surfing on that thing is
so slow, it's not worth plugging in.

Right now, I'm wondering if some free version of Macrium Reflect might
be enough to clean up C:. I'm off to try some experiments... What
I don't know at the moment, is whether Macrium would be enough on its
own. There is a free version, a download from CNET, and the first job
will be to determine whether it's got some toolbar in it or not :-(
Some of these downloads, are packed with hacker style packers, and
it makes it hard for me to verify they're clean. And this one is
too big to pop up onto virustotal.com for a check. (I use virustotal
as much for the unpacking information, as I do for virus scans. It
helps tell me what tricks are being used. All half decent virus scanners
know all the packing tricks, but my tool of choice, 7-ZIP, isn't
very good at it.)

http://www.macrium.com/reflectfree.aspx

I'm not testing this on a live system, but using a virtual machine
for some measure of safety.

    Paul- Hide quoted text -

- Show quoted text -

I have to be honest Paul, you’re getting way past me on this. I can
barely
Keep up with you or understand what you’re talking about. (no
offense)

I realize I still have a ‘sleeping problem’ with my computer. I ran a
Spybot update and it failed once again to complete its passive
immunization with (27) unprotected items. This happened before but it
cleared up after the next update. Also when I ran defrag it found
fragmented files.

SO it seems that although the computer is acting normal for the
present I’m going to have to reformat and partition the HD eventually
and probably sooner than later is best?

Any suggestions or hints on doing it one way or another? Please keep
it simple for the simple minded *L*

Thanks,
Robert
 

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

Similar Threads


Top