NT 4.0 Repair Troubles

[Robert William Vesterman]

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]

See in-line comments

Robert William Vesterman wrote:
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).
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.
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.

Still needs the Emergency Repair Disk.

<<snipped>>
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. ----------

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>>
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]

On Thu, 06 Nov 2003 09:15:30 -0800, Ghostrider <-00-@fitron.142>
wrote:
See in-line commentsRobert William Vesterman wrote: 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 donot install it. Windows NT may not handle well any application thatwas poorly ported over especially for 32-bit operation or that will notwork with the 16-bit virtual window (and emulator).

Okay. Too late.
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.
<<snipped>> 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. ----------Running setup and re-installing on top of a failed installation is not a goodidea. 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.
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, PowerQuestDriveImage, etc., then do the restore. It should bring the system to thepoint when the image file was created. There is nothing to repair at thispoint. Attempting to repeat the flawed install of the application withoutfirst 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]

Robert William Vesterman wrote:
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>>
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]

On Thu, 06 Nov 2003 17:09:10 -0800, Ghostrider <-00-@fitron.142>
wrote:
Robert William Vesterman wrote: 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>> 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 essentialapplication to the new, parallel installation and resume working with thepresent state of the data set. An alternate option would be to use theparallel installation to back up the data sets, if they can be discretelyidentified, restore the system using the backup image file(s) and reloadthe dataset(s) to bring them to current state for the application. Unlessone has plenty of time available, it is far easier to re-build a system fromkey parts that may still be available, as it appears here, then pursue themicrosurgical approach of manually repairing the Windows registry. GL.

Okay. Thanks.

Bob Vesterman.