desperately need help - can't get into windows!
Rolf Inge Holden
When starting my laptop with winxp installed I get the following message:
"windows could not start because the following file is missing or corrupt:
\winnt\system32\config\system
You can attempt to repair this file by starting windows setup using the
original setup cd-rom
Select 'r' at the first screen to start repair."
How can i solve this problem without having to format my hd and installing
winxp from scratch??
Any advice is greatly appreciated!
Finge
Walter Clayton
part of the registry.
Follow the directions you've been given. A repair install simply reinstalls
the OS over the top of itself. Unless there is a problem with another
registry hive you'll be fine and you'll come out of setup with everything
intact.
Note however that it is very unusual for the system to loose part of the
registry. In this instance do what you can to back critical things up in
case you have a much larger problem than simple corruption in the system
hive.
--
Walter Clayton - MS MVP(MPS-D)
Associate Expert
http://www.microsoft.com/windowsxp/expertzone
Any technology distinguishable from magic is insufficiently advanced.
http://www.dts-l.org
http://support.microsoft.com/servicedesks/fileversion/default.asp
"Rolf Inge Holden" <fi...@nospam.bigfoot.com> wrote in message
news:#h0I3LVmBHA.2448@tkmsftngp02...
cqu...@iafrica.com
<w-cla...@SPmailandnewsAM.com> wrote:
>The file being refered to is the system hive. It's what contains HKLM\SYSTEM
>part of the registry. Follow the directions you've been given. A repair install
>simply reinstalls the OS over the top of itself.
See my earlier QRtSH about verifying hardware integrity first.
Writing several megs of code to a dying file system or hard drive
through the lens of bad RAM would be... Bad.
>Note it is very unusual for the system to lose part of the registry.
Indeed. More likely you've lost the directory; if kinked, an aut-fix
after a bad exit is likely to throw it away. Permanently.
>In this instance do what you can to back critical things up in
>case you have a much larger problem than simple corruption in
>the system hive.
Be interested to see how to do that, if you are living on an NTFS
volume that DOS mode can't see.
>-------------------- ----- ---- --- -- - - - -
This year I'm not going to make any resolutions
>-------------------- ----- ---- --- -- - - - -
Walter Clayton
news:3c3d6345...@news.iafrica.com...
> On Wed, 9 Jan 2002 16:48:11 -0500, "Walter Clayton"
> <w-cla...@SPmailandnewsAM.com> wrote:
>
> >The file being refered to is the system hive. It's what contains
HKLM\SYSTEM
> >part of the registry. Follow the directions you've been given. A repair
install
> >simply reinstalls the OS over the top of itself.
>
> See my earlier QRtSH about verifying hardware integrity first.
> Writing several megs of code to a dying file system or hard drive
> through the lens of bad RAM would be... Bad.
>
> >Note it is very unusual for the system to lose part of the registry.
>
> Indeed. More likely you've lost the directory; if kinked, an aut-fix
> after a bad exit is likely to throw it away. Permanently.
>
> >In this instance do what you can to back critical things up in
> >case you have a much larger problem than simple corruption in
> >the system hive.
>
> Be interested to see how to do that, if you are living on an NTFS
> volume that DOS mode can't see.
>
Several possibilities exist:
Hang another drive and do a 3rd party image.
Grab the DOS NTFS driver from http://www.sysinternals.com
...and relatively new discovery for me, with multiple machines, Sysinternals
has other tools for recovering NTFS or FAT partitions in this instance
assuming no severe on disk data corruption. Check out the utilities
sections, especially NTRecover and Remote Recover. I don't know if they're
NTFS 5.1 capable however.
cqu...@iafrica.com
>news:3c3d6345...@news.iafrica.com...
>> On Wed, 9 Jan 2002 16:48:11 -0500, "Walter Clayton"
>> <w-cla...@SPmailandnewsAM.com> wrote:
>> >In this instance do what you can to back critical things up in
>> >case you have a much larger problem than simple corruption in
>> >the system hive.
>> Be interested to see how to do that, if you are living on an NTFS
>> volume that DOS mode can't see.
>Several possibilities exist:
>Hang another drive and do a 3rd party image.
>Grab the DOS NTFS driver from http://www.sysinternals.com
Is it still read-only? (thinking of the av situation)
>...and relatively new discovery for me, with multiple machines, Sysinternals
>has other tools for recovering NTFS or FAT partitions in this instance
>assuming no severe on disk data corruption. Check out the utilities
>sections, especially NTRecover and Remote Recover. I don't know if they're
>NTFS 5.1 capable however.
"Remote Recover" sounds like it requires NT to run on the stricken
box, unless you drop the drive into a known-good box, then recover
remotely from a 3rd box. That isn't as pointless as it sounds if the
expertise is "remote", but there's enough local tech to do the drive
pull and drop-in (thinking staff sysadmin + specialist co-operation)
It's a pity the RC doesn't run 3rd-party apps; I was hoping that would
be tomorrow's mOS. Maybe it will be; after all, Windows 1.0 and
DOSShell 4.0 weren't too impressive either.
Walter Clayton
hosed box. The difference between it and NTRecover is serial connection vs.
NIC. In either instance you boot the hosed box from diskette, go to a
functioning NT box that's attached appropriately (serial or NIC), mount the
hosed drive and do recovery.
The free versions are read only. Only the pay-for version will do writes on
the hosed machine and that only on demand since the machine running full
blown won't have a reason to touch a networked drive in the same manner as a
local drive.
--
Walter Clayton - MS MVP(MPS-D)
Associate Expert
http://www.microsoft.com/windowsxp/expertzone
Any technology distinguishable from magic is insufficiently advanced.
http://www.dts-l.org
http://support.microsoft.com/servicedesks/fileversion/default.asp
<cqu...@iafrica.com> wrote in message
news:3c3f8362....@news.iafrica.com...
cqu...@iafrica.com
<w-cla...@SPmailandnewsAM.com> wrote:
>Nope. Remote recovery does not require any NT kernel to be running on the
>hosed box. The difference between it and NTRecover is serial connection vs.
>NIC. In either instance you boot the hosed box from diskette, go to a
>functioning NT box that's attached appropriately (serial or NIC), mount the
>hosed drive and do recovery.
Nice! Conceptually, sounds like a combination of NTFS reader and Lap
Link (with LAN support). I like...
>The free versions are read only. Only the pay-for version will do writes on
>the hosed machine and that only on demand since the machine running full
>blown won't have a reason to touch a networked drive in the same manner as a
>local drive.
Only Q there, with respect to the malware context, is; how confidently
can one handle septic material in NT without the risk of something
stupid causing it to be run? Contenders...
"View As Web Page"
AutoRun.inf processing
SR including septic material within backup data
Basically, you'd want to be sure the OS (and anything else running)
will ignore everything coming from the other drive, both as it arrives
and is created, and when you browse around the dirs created later.
Perhaps SystemInternals will become the "new Norton"? I kinda lost
faith in the old one (which is as "Norton" as KFC is "Col Saunders")
Walter Clayton
Note: This is a client-server scenario that Sysinternals is creating.
SR doesn't touch networked volumes and autorun is easy to snuff out as a
possible issue.
View as web page is the only remote possibility, but that doesn't come into
play until you start to browse the client. So you mount, AV scan and then
proceed.
This is the ultimate in safe environments unless and until someone discovers
some hook of course.
My respect for Sysinternals is going up on a regular basis. ;-)
Now if they'd just update some of their tools for NTFS 3.1.
--
Walter Clayton - MS MVP(MPS-D)
Associate Expert
http://www.microsoft.com/windowsxp/expertzone
Any technology distinguishable from magic is insufficiently advanced.
http://www.dts-l.org
http://support.microsoft.com/servicedesks/fileversion/default.asp
<cqu...@iafrica.com> wrote in message
news:3c401dd5...@news.iafrica.com...
cqu...@iafrica.com
<w-cla...@SPmailandnewsAM.com> wrote:
>Either NTRecover or Remote Recover will not trigger any automatic action.
>Note: This is a client-server scenario that Sysinternals is creating.
>SR doesn't touch networked volumes and autorun is easy to snuff out as a
>possible issue.
The worry I would have is that when the helper system copies data off
the stricken system via LAN, this material could be either autorun by
the system in some way, or included in SR data (not by SR scooping off
the remote system, but scooping locally as the files are copied
there). There's also the risk that something like "View As Web Page"
(which is now so buried you probably can't turn it off) might autorun
something when the recovered data was browsed locally, as one might do
to verify it is all there (Rt-click, Properties, byte/file count etc.)
>View as web page is the only remote possibility, but that doesn't come into
>play until you start to browse the client. So you mount, AV scan and then
>proceed. This is the ultimate in safe environments unless and until someone
>discovers some hook of course.
If there's a combination of suspect disk/file system and malware on
the stricken system, then you will typically want to transfer data off
it, then check it for malware locally. This is in fact a very common
(almost typical) scenario, of two likely variations:
1) Diagnostics show HD damage
2) So HD use to be minimized and no writes to disk permitted
3) Therefore, pull data off HD directly to other system or HD
4) Thereafter, virus check recovered data as copied
5) In parallel with (4); virus check, diags, forensics on stricken HD
1) Hairy history suggests HD damage and/or insane file system
2) So HD use to be minimized and no writes to disk permitted
3) Therefore, pull data off HD directly to other system or HD
4) Thereafter, do file system repair incriment
5) Repeat (3-4) until file system is sane (keeping all data pulls)
6) Thereafter, virus check all recovered data as copied
7) In parallel with (6); virus check, diags, forensics on stricken HD
In both cases, you daren't run av check and especially attempt av
repair on the sick system until data is pulled, for all incriments of
file system sanity from minimal-change to sane-but-?botched.
Thereafter you would av scan and perhaps fix the recovered data, and
only when the stricken HD is disposable would you av check that for
forensics and for malware not transferred with data (e.g. boot
infectors). The risk being that you are transferring possibly
infected material onto the recovery PC and you want to be certain that
any malware present does not get launched by the system before such
time as a check can be done.
You'd also want to make sure no infected material gets caught up in
the wheels of SR, and best way to do that would be to reserve a volume
as an in-bay for such material, and exclude this volume from SR.
>My respect for Sysinternals is going up on a regular basis. ;-)
>Now if they'd just update some of their tools for NTFS 3.1
Yes - certainly sounds good :-)