Discussion:
NT 4.0 Repair Troubles
(too old to reply)
Robert William Vesterman
2003-11-06 15:43:31 UTC
Permalink
Hi. I'm having problems repairing an existing NT installation; I'm
hoping that someone here knows what I can do to fix it. Thanks in
advance for any help. Here is the history:

An application was being installed on an existing NT 4.0 machine. The
install process called for a reboot, and after it rebooted, it did not
successfully come back to NT. Instead, a blue screen came up saying
that physical memory was being dumped, after which the machine
essentially halted. Subsequent reboots did the same thing.

Unfortunately, no emergency repair disk was available. So, I tried to
repair from the installation media. Specifically, I told it to fix
the system portion of the registry, and to validate system files.

It was then able to reboot to NT, but whenever I tried to log on, I
would get an error C00000DF. Some poking around on the web revealed
that this was likely due to various files from the original NT
installation media no longer being able to deal with the SAM/Security
information written by newer versions of those files (i.e. from
service pack 4 or later). So, I did what was suggested by this
Knowledge Base article:

http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q196/6/03.ASP&NoWebContent=1

Specifically, I copied the i386 directory of the installation media to
the i386 directory of the hard drive, then renamed certain files out
of the way (e.g. samsrv.dl_ was renamed to samsrv.org), and then
copied the newer versions of those files from the service pack (6a,
specifically) to the hard drive.

One quick question before I continue: the KB article says "copy these
same six files" from the service pack, but those same six files do not
exist... uncompressed versions of them do (e.g. samsrv.dll instead of
samsrv.dl_). I assume that copying the uncompressed versions to the
hard drive's i386 is sufficient? That's what I did.

Anyway, to continue, I then ran winnt /b from the hard drive's i386
directory. Now, whenever I reboot, I get the following message:

----------
STOP: c0000263 {Driver Entry Point Not Found}

The \SystemRoot\System32\Drivers\Msfs.SYS device driver could not
locate the entry point MmUserProbeAddress in the driver ntoskrnl.exe.

Restart and set the recovery options in the system control panel or
the /CRASHDEBUG system start option. If this message reappears,
contact your system administrator or technical support group.
----------

I have so far been unable to find anything relating to this error in
the KB, the web, usenet, or anywhere else. Anybody have any ideas?

One possibility: I have a copy of the hard drive as it existed just
after the initial crash, and just before I started mucking around on
it (e.g. trying to repair NT). So, I'm thinking that maybe if I
restore that copy, and then do another repair of the system portion of
the registry but this time not tell it to validate system files, maybe
it will work since I'll still have the correct version of the various
dlls (such as samsrv.dll) to deal with the SAM.... Am I on the right
track here?

Again, thanks in advance for any help.

Bob Vesterman.
Ghostrider
2003-11-06 17:15:30 UTC
Permalink
See in-line comments
Post by Robert William Vesterman
An application was being installed on an existing NT 4.0 machine. The
install process called for a reboot, and after it rebooted, it did not
successfully come back to NT. Instead, a blue screen came up saying
that physical memory was being dumped, after which the machine
essentially halted. Subsequent reboots did the same thing.
If the application was not written to be used in Windows NT, then do
not install it. Windows NT may not handle well any application that
was poorly ported over especially for 32-bit operation or that will not
work with the 16-bit virtual window (and emulator).
Post by Robert William Vesterman
Unfortunately, no emergency repair disk was available. So, I tried to
repair from the installation media. Specifically, I told it to fix
the system portion of the registry, and to validate system files.
Always prepare an Emergency Repair Disk.
Post by Robert William Vesterman
It was then able to reboot to NT, but whenever I tried to log on, I
would get an error C00000DF. Some poking around on the web revealed
that this was likely due to various files from the original NT
installation media no longer being able to deal with the SAM/Security
information written by newer versions of those files (i.e. from
service pack 4 or later). So, I did what was suggested by this
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q196/6/03.ASP&NoWebContent=1
Specifically, I copied the i386 directory of the installation media to
the i386 directory of the hard drive, then renamed certain files out
of the way (e.g. samsrv.dl_ was renamed to samsrv.org), and then
copied the newer versions of those files from the service pack (6a,
specifically) to the hard drive.
Still needs the Emergency Repair Disk.

<<snipped>>
Post by Robert William Vesterman
Anyway, to continue, I then ran winnt /b from the hard drive's i386
----------
STOP: c0000263 {Driver Entry Point Not Found}
The \SystemRoot\System32\Drivers\Msfs.SYS device driver could not
locate the entry point MmUserProbeAddress in the driver ntoskrnl.exe.
Restart and set the recovery options in the system control panel or
the /CRASHDEBUG system start option. If this message reappears,
contact your system administrator or technical support group.
----------
Running setup and re-installing on top of a failed installation is not a good
idea. Might have been better to have done a "parallel" installation.

<<snipped>>
Post by Robert William Vesterman
One possibility: I have a copy of the hard drive as it existed just
after the initial crash, and just before I started mucking around on
it (e.g. trying to repair NT). So, I'm thinking that maybe if I
restore that copy, and then do another repair of the system portion of
the registry but this time not tell it to validate system files, maybe
it will work since I'll still have the correct version of the various
dlls (such as samsrv.dll) to deal with the SAM.... Am I on the right
track here?
If this is an image file created by using Symantec Ghost, PowerQuest
DriveImage, etc., then do the restore. It should bring the system to the
point when the image file was created. There is nothing to repair at this
point. Attempting to repeat the flawed install of the application without
first knowing whether it can be used in Windows NT is not advised. And,
take the opportunity to make the ERD.
Robert William Vesterman
2003-11-06 17:57:42 UTC
Permalink
Post by Ghostrider
See in-line comments
Post by Robert William Vesterman
An application was being installed on an existing NT 4.0 machine. The
install process called for a reboot, and after it rebooted, it did not
successfully come back to NT. Instead, a blue screen came up saying
that physical memory was being dumped, after which the machine
essentially halted. Subsequent reboots did the same thing.
If the application was not written to be used in Windows NT, then do
not install it. Windows NT may not handle well any application that
was poorly ported over especially for 32-bit operation or that will not
work with the 16-bit virtual window (and emulator).
Okay. Too late.
Post by Ghostrider
Post by Robert William Vesterman
Unfortunately, no emergency repair disk was available. So, I tried to
repair from the installation media. Specifically, I told it to fix
the system portion of the registry, and to validate system files.
Always prepare an Emergency Repair Disk.
Okay. Too late.
Post by Ghostrider
<<snipped>>
Post by Robert William Vesterman
Anyway, to continue, I then ran winnt /b from the hard drive's i386
----------
STOP: c0000263 {Driver Entry Point Not Found}
The \SystemRoot\System32\Drivers\Msfs.SYS device driver could not
locate the entry point MmUserProbeAddress in the driver ntoskrnl.exe.
Restart and set the recovery options in the system control panel or
the /CRASHDEBUG system start option. If this message reappears,
contact your system administrator or technical support group.
----------
Running setup and re-installing on top of a failed installation is not a good
idea. Might have been better to have done a "parallel" installation.
I have (also) done a parallel installation. Now what? I need to do
this so that I can access the state of an existing application (not
the one that caused the problems in the first place - one that has
been running fine on the box for years). I can get to the data files
just fine, but the application itself is not installed on the parallel
installation, and the data files are essentially useless without the
application.
Post by Ghostrider
Post by Robert William Vesterman
One possibility: I have a copy of the hard drive as it existed just
after the initial crash, and just before I started mucking around on
it (e.g. trying to repair NT). So, I'm thinking that maybe if I
restore that copy, and then do another repair of the system portion of
the registry but this time not tell it to validate system files, maybe
it will work since I'll still have the correct version of the various
dlls (such as samsrv.dll) to deal with the SAM.... Am I on the right
track here?
If this is an image file created by using Symantec Ghost, PowerQuest
DriveImage, etc., then do the restore. It should bring the system to the
point when the image file was created. There is nothing to repair at this
point. Attempting to repeat the flawed install of the application without
first knowing whether it can be used in Windows NT is not advised. And,
take the opportunity to make the ERD.
I am not concerned with installing the application that caused the
crash in the first place. I am concerned about retrieving data that
was on the machine.

Bob Vesterman.
Ghostrider
2003-11-07 01:09:10 UTC
Permalink
Post by Robert William Vesterman
I have (also) done a parallel installation. Now what? I need to do
this so that I can access the state of an existing application (not
the one that caused the problems in the first place - one that has
been running fine on the box for years). I can get to the data files
just fine, but the application itself is not installed on the parallel
installation, and the data files are essentially useless without the
application.
<<snipped>>
Post by Robert William Vesterman
I am not concerned with installing the application that caused the
crash in the first place. I am concerned about retrieving data that
was on the machine.
Bob Vesterman.
Is something missing here? One option could be to re-install the essential
application to the new, parallel installation and resume working with the
present state of the data set. An alternate option would be to use the
parallel installation to back up the data sets, if they can be discretely
identified, restore the system using the backup image file(s) and reload
the dataset(s) to bring them to current state for the application. Unless
one has plenty of time available, it is far easier to re-build a system from
key parts that may still be available, as it appears here, then pursue the
microsurgical approach of manually repairing the Windows registry. GL.
Robert William Vesterman
2003-11-07 22:15:57 UTC
Permalink
Post by Ghostrider
Post by Robert William Vesterman
I have (also) done a parallel installation. Now what? I need to do
this so that I can access the state of an existing application (not
the one that caused the problems in the first place - one that has
been running fine on the box for years). I can get to the data files
just fine, but the application itself is not installed on the parallel
installation, and the data files are essentially useless without the
application.
<<snipped>>
Post by Robert William Vesterman
I am not concerned with installing the application that caused the
crash in the first place. I am concerned about retrieving data that
was on the machine.
Bob Vesterman.
Is something missing here? One option could be to re-install the essential
application to the new, parallel installation and resume working with the
present state of the data set. An alternate option would be to use the
parallel installation to back up the data sets, if they can be discretely
identified, restore the system using the backup image file(s) and reload
the dataset(s) to bring them to current state for the application. Unless
one has plenty of time available, it is far easier to re-build a system from
key parts that may still be available, as it appears here, then pursue the
microsurgical approach of manually repairing the Windows registry. GL.
Okay. Thanks.

Bob Vesterman.

Loading...