Registry Changes Lost Upon Reboot

  • Thread starter Thread starter Randall Schulz
  • Start date Start date
R

Randall Schulz

Hi,

This problem is really getting the best of me.

Registry changes (I believe only to the Software registry
hive) appear to be recorded successfully, but are gone
after the next system restart. Changes to system settings
appear to retained properly.

I have applied the Microsoft chkreg.exe several times.
Sometimes it seems to alleviate the problem for one or two
reboots, but then it's back again. On the most recent
reboot, which included the use of chkreg, the previous
session's registry changes were once again lost.

I'm running Windows 2000 Pro SP4 and am completely
up-to-date with Microsoft patches (at least those released
via Windowsupdate.microsoft.com).

I know this is a rather sketchy report. I'd be happy to
fill in any details that would be required for a precise
diagnosis. I'm fairly competent with computers (I'm a
long-time professional programmer) and I have an adequate
understanding of Windows overall, but I'm not really an
in-depth expert. I can certainly run any diagnostics that
might be required to diagnose the problem or any repair
tools required to fix it. I have the Windows 2000
Professional Resource Kit software installed.

Thanks in advance for any help you all can give me.

Randall Schulz
 
P.S.

If it will help clarify which portion of the registry has
the problem, the way I test if changes are lost is to play
a game or two of Freecell. When the problem strikes, my
scores revert to their previous values. Typically desktop
icon positions are not retained as well when the problem
occurs. Other applications show symptoms, too, but they're
not likely to exist on most users systems.

Randall Schulz
 
P.S.

If it will help clarify which portion of the registry has
the problem, the way I test if changes are lost is to play
a game or two of Freecell. When the problem strikes, my
scores revert to their previous values. Typically desktop
icon positions are not retained as well when the problem
occurs. Other applications show symptoms, too, but they're
not likely to exist on most users systems.

Randall Schulz
 
Not sure if this is the reason but maybe Delayed Write to Disk is
causing the changes to not be saved? Device Manager- hardrive properties
, uncheck Write Cache enabled and test?
 
Not sure if this is the reason but maybe Delayed Write to Disk is
causing the changes to not be saved? Device Manager- hardrive properties
, uncheck Write Cache enabled and test?
 
In said:
P.S.

If it will help clarify which portion of the registry has
the problem, the way I test if changes are lost is to play
a game or two of Freecell. When the problem strikes, my
scores revert to their previous values. Typically desktop
icon positions are not retained as well when the problem
occurs. Other applications show symptoms, too, but they're
not likely to exist on most users systems.

Are there any Event Log entries such as USEENV?

Does this occur with just the one Profile or for all accounts on the
machine?

Are you limiting your evidence to Freecell or are other HKCU values
beiong lost?
 
In said:
P.S.

If it will help clarify which portion of the registry has
the problem, the way I test if changes are lost is to play
a game or two of Freecell. When the problem strikes, my
scores revert to their previous values. Typically desktop
icon positions are not retained as well when the problem
occurs. Other applications show symptoms, too, but they're
not likely to exist on most users systems.

Are there any Event Log entries such as USEENV?

Does this occur with just the one Profile or for all accounts on the
machine?

Are you limiting your evidence to Freecell or are other HKCU values
beiong lost?
 
-----Original Message-----


Are there any Event Log entries such as USEENV?

Ahh... Bingo!

-==-
Section: Application
Source: Userenv
Category: None
Type: Error
Event ID: 1000
User: NT AUTHORITY\SYSTEM

Description:
Windows cannot unload your registry file.
If you have a roaming profile, your settings
are not replicated. Contact your administrator.

DETAIL - Access is denied. , Build number ((2195)).
-==-

There is a variant on this one, occurring at a differnt
time (not the same reboot), that is similar except it say
"cannot unload your registry class file" instead of "cannot
unload your registry file".

No domain controller, no roaming profile.

So... I'm the administrator. What's the prescription for
fixing this?

I had a hunch this had to do with permissions on the hive
files, but they all seem to bear the same ACL, yet only
application software settings are lost. Perhaps I'm not
really looking in the right place. Aren't the hive files
the ones in \WINNT\system32\Config?

Another thing, those errors do not correspond (in terms of
dates) to the latest failures to retain registry
modifications. There are only three of them: One is from
March, the other two date back a day or so. Nonetheless,
presumably they're relevant clues to what's still happening
now.

Does this occur with just the one Profile
or for all accounts on the machine?

That's a good question. This is essentially a single-user
machine, though I keep a separate administrator account
even though the account I use on a daily basis has full
administrative privileges.
Are you limiting your evidence to Freecell
or are other HKCU values beiong lost?

As I said, several applications, including Windows
Explorer's record of desktop icon positions, are lost when
this symptom occurs, which is frequently.


Thanks for pointing me in the right direction. If you can
also suggest how to fix the issue, I'd be very grateful.

Randall Schulz
 
-----Original Message-----


Are there any Event Log entries such as USEENV?

Ahh... Bingo!

-==-
Section: Application
Source: Userenv
Category: None
Type: Error
Event ID: 1000
User: NT AUTHORITY\SYSTEM

Description:
Windows cannot unload your registry file.
If you have a roaming profile, your settings
are not replicated. Contact your administrator.

DETAIL - Access is denied. , Build number ((2195)).
-==-

There is a variant on this one, occurring at a differnt
time (not the same reboot), that is similar except it say
"cannot unload your registry class file" instead of "cannot
unload your registry file".

No domain controller, no roaming profile.

So... I'm the administrator. What's the prescription for
fixing this?

I had a hunch this had to do with permissions on the hive
files, but they all seem to bear the same ACL, yet only
application software settings are lost. Perhaps I'm not
really looking in the right place. Aren't the hive files
the ones in \WINNT\system32\Config?

Another thing, those errors do not correspond (in terms of
dates) to the latest failures to retain registry
modifications. There are only three of them: One is from
March, the other two date back a day or so. Nonetheless,
presumably they're relevant clues to what's still happening
now.

Does this occur with just the one Profile
or for all accounts on the machine?

That's a good question. This is essentially a single-user
machine, though I keep a separate administrator account
even though the account I use on a daily basis has full
administrative privileges.
Are you limiting your evidence to Freecell
or are other HKCU values beiong lost?

As I said, several applications, including Windows
Explorer's record of desktop icon positions, are lost when
this symptom occurs, which is frequently.


Thanks for pointing me in the right direction. If you can
also suggest how to fix the issue, I'd be very grateful.

Randall Schulz
 
In said:
Ahh... Bingo!

-==-
Section: Application
Source: Userenv
Category: None
Type: Error
Event ID: 1000
User: NT AUTHORITY\SYSTEM

Description:
Windows cannot unload your registry file.
If you have a roaming profile, your settings
are not replicated. Contact your administrator.

DETAIL - Access is denied. , Build number ((2195)).
-==-

There is a variant on this one, occurring at a differnt
time (not the same reboot), that is similar except it say
"cannot unload your registry class file" instead of "cannot
unload your registry file".

No domain controller, no roaming profile.

So... I'm the administrator. What's the prescription for
fixing this?

That "failure to unload" may or may not be the cause of lost registry
writes. I suggested it only because it _might_ be. This slew of
different messages regarding "failure to unload" has been around
through various OS NTx releases and Service Packs and has never been
100% permanently resolved to this day. The topic is complex....

You can try stopping the Spooler Service prior to logoff/shutdown.
That helps in some cases. You can write to
rcaron [at] microsoft.com
and ask for a developmental utility UPHclean that seems to work well.
There was also a specific W2K HotFix that cause this problem. It may
be 329170 (but bot certain).
I had a hunch this had to do with permissions on the hive
files, but they all seem to bear the same ACL, yet only
application software settings are lost. Perhaps I'm not
really looking in the right place. Aren't the hive files
the ones in \WINNT\system32\Config?

Yes. But check your account's HKCU too (ntuser.dat) just in case.

Any chance you are growing the total registry size beyond the
"Maximum" setting? System Properties, Advanced, Performance Options,
Change ?
Another thing, those errors do not correspond (in terms of
dates) to the latest failures to retain registry
modifications. There are only three of them: One is from
March, the other two date back a day or so. Nonetheless,
presumably they're relevant clues to what's still happening
now.



That's a good question. This is essentially a single-user
machine, though I keep a separate administrator account
even though the account I use on a daily basis has full
administrative privileges.

Try the alternate account. If that works it may be that your
(primary) account registry is somehow corrupt. In that case you may
need to rebuild it. This assumes that the problem is in
<account>\ntuser.dat and not <system>\SOFTWARE though. I may have
missed it, but am assuming HKCU and not HKLM\Software...

[ ]
As I said, several applications, including Windows
Explorer's record of desktop icon positions, are lost when
this symptom occurs, which is frequently.
Thanks for pointing me in the right direction.

I don't know that I have. Just some ideas. I have not personally
suffered from the condition there. And I assume you have used up-to-
date Anti-Virus, A-Trojan, and A-Spyware/Adware tools. And that no
tools are "locking" the registry on purpose.
 
In said:
Ahh... Bingo!

-==-
Section: Application
Source: Userenv
Category: None
Type: Error
Event ID: 1000
User: NT AUTHORITY\SYSTEM

Description:
Windows cannot unload your registry file.
If you have a roaming profile, your settings
are not replicated. Contact your administrator.

DETAIL - Access is denied. , Build number ((2195)).
-==-

There is a variant on this one, occurring at a differnt
time (not the same reboot), that is similar except it say
"cannot unload your registry class file" instead of "cannot
unload your registry file".

No domain controller, no roaming profile.

So... I'm the administrator. What's the prescription for
fixing this?

That "failure to unload" may or may not be the cause of lost registry
writes. I suggested it only because it _might_ be. This slew of
different messages regarding "failure to unload" has been around
through various OS NTx releases and Service Packs and has never been
100% permanently resolved to this day. The topic is complex....

You can try stopping the Spooler Service prior to logoff/shutdown.
That helps in some cases. You can write to
rcaron [at] microsoft.com
and ask for a developmental utility UPHclean that seems to work well.
There was also a specific W2K HotFix that cause this problem. It may
be 329170 (but bot certain).
I had a hunch this had to do with permissions on the hive
files, but they all seem to bear the same ACL, yet only
application software settings are lost. Perhaps I'm not
really looking in the right place. Aren't the hive files
the ones in \WINNT\system32\Config?

Yes. But check your account's HKCU too (ntuser.dat) just in case.

Any chance you are growing the total registry size beyond the
"Maximum" setting? System Properties, Advanced, Performance Options,
Change ?
Another thing, those errors do not correspond (in terms of
dates) to the latest failures to retain registry
modifications. There are only three of them: One is from
March, the other two date back a day or so. Nonetheless,
presumably they're relevant clues to what's still happening
now.



That's a good question. This is essentially a single-user
machine, though I keep a separate administrator account
even though the account I use on a daily basis has full
administrative privileges.

Try the alternate account. If that works it may be that your
(primary) account registry is somehow corrupt. In that case you may
need to rebuild it. This assumes that the problem is in
<account>\ntuser.dat and not <system>\SOFTWARE though. I may have
missed it, but am assuming HKCU and not HKLM\Software...

[ ]
As I said, several applications, including Windows
Explorer's record of desktop icon positions, are lost when
this symptom occurs, which is frequently.
Thanks for pointing me in the right direction.

I don't know that I have. Just some ideas. I have not personally
suffered from the condition there. And I assume you have used up-to-
date Anti-Virus, A-Trojan, and A-Spyware/Adware tools. And that no
tools are "locking" the registry on purpose.
 
-----Original Message-----
That "failure to unload" may or may not be the cause
of lost registry writes. I suggested it only because
it _might_ be. This slew of different messages
regarding "failure to unload" has been around
through various OS NTx releases and Service Packs
and has never been 100% permanently resolved to this
day. The topic is complex....

There appear to be many more related messages in
"\WINNT\Debug\UserMode\userenv.log":

USERENV(c8.b0) 08:49:56:484 MyRegUnLoadKey: Hive unload for
S-1-5-21-1417001333-1677128483-1801674531-1002_Classes
failed due to open registry key. Windows will try
unloading the registry hive once a second for the next 60
seconds (max).
USERENV(c8.b0) 08:50:56:484 MyRegUnLoadKey: Windows was not
able to unload the registry hive.
USERENV(c8.b0) 08:50:56:484 MyRegUnLoadKey: Failed to
unmount hive 5
USERENV(c8.b0) 08:50:56:484 UnLoadClassHive: failed to
unload classes key with 5
USERENV(c8.b0) 08:50:56:484 DumpOpenRegistryHandle: 3 user
registry Handles leaked from
\Registry\User\S-1-5-21-1417001333-1677128483-1801674531-1002_Classes
USERENV(c8.b0) 15:00:12:578 UnloadUserProfile: Failed to
flush the current user key, error = 1016

The last one, with error = 1016, is by far the most common
log entry.

You can try stopping the Spooler Service prior to
logoff/shutdown. That helps in some cases. You can
write to rcaron [at] microsoft.com and ask for a
developmental utility UPHclean that seems to work
well. There was also a specific W2K HotFix that cause
this problem. It may be 329170 (but bot certain).

Thanks for the up-to-date address for Robin Caron. All
other references I could find to UPHClean mentioned her
now-defunct Hotmail account.

Yes. But check your account's HKCU too (ntuser.dat)
just in case.

Check how, exactly?

One seeming anomaly: The Gnu "file" command (part of
Cygwin) reports different file types for my ntuser.dat
files. It identifies my ntuser.dat file as "executable",
which seems odd. It identifies the other three ntuser.dat
files as "Windows NT Registry file". (The "file" command
looks for magic numbers and other content patterns to make
its determination). Although there are only two ".LOG"
counterparts, they show the same misidentification pattern.

That misidentification may be spurious (the signatures used
by "file" may not be adequately specified to properly
identify all registry files) or the hive file(s) could be
corrupt somehow. However, if that file were not mostly
intact, it seems I would have much bigger registry problems
than I do. Perhaps not...

Can ntuser.dat be repaired? Are their tools that will
diangose that file's integrity? Does chkreg.exe process
user hives, too, or only system ones. Absent tools to
diagnose and / or repair an ntuser.dat file, what's to be done?

Any chance you are growing the total registry size
beyond the "Maximum" setting? System Properties,
Advanced, Performance Options, Change?

No. I checked that already.

Another thing, those errors do not correspond
(in terms of dates) to the latest failures to
retain registry modifications. There are only
three of them: One is from March, the other two
date back a day or so. Nonetheless, presumably
they're relevant clues to what's still happening now.



That's a good question. This is essentially a
single-user machine, though I keep a separate
administrator account even though the account I
use on a daily basis has full administrative
privileges.

Try the alternate account. If that works it may be
that your (primary) account registry is somehow corrupt.
In that case you may >need to rebuild it. This assumes
that the problem is in <account>\ntuser.dat and not
<system>\SOFTWARE though. I may have >missed it, but
am assuming HKCU and not HKLM\Software...

[ ]
As I said, several applications, including Windows
Explorer's record of desktop icon positions, are
lost when this symptom occurs, which is frequently.
Thanks for pointing me in the right direction.

I don't know that I have. Just some ideas. I have not
personally suffered from the condition there. And I
assume you have used up-to-date Anti-Virus, A-Trojan,
and A-Spyware/Adware tools. And that no tools are
"locking" the registry on purpose.

Yes, my Norton firewall and virus tools are kept up-to-date
with each Wednesday's LiveUpdate. Likewise for MS-supplied
patches.


Thanks again for all your help.

Randall Schulz
 
-----Original Message-----
That "failure to unload" may or may not be the cause
of lost registry writes. I suggested it only because
it _might_ be. This slew of different messages
regarding "failure to unload" has been around
through various OS NTx releases and Service Packs
and has never been 100% permanently resolved to this
day. The topic is complex....

There appear to be many more related messages in
"\WINNT\Debug\UserMode\userenv.log":

USERENV(c8.b0) 08:49:56:484 MyRegUnLoadKey: Hive unload for
S-1-5-21-1417001333-1677128483-1801674531-1002_Classes
failed due to open registry key. Windows will try
unloading the registry hive once a second for the next 60
seconds (max).
USERENV(c8.b0) 08:50:56:484 MyRegUnLoadKey: Windows was not
able to unload the registry hive.
USERENV(c8.b0) 08:50:56:484 MyRegUnLoadKey: Failed to
unmount hive 5
USERENV(c8.b0) 08:50:56:484 UnLoadClassHive: failed to
unload classes key with 5
USERENV(c8.b0) 08:50:56:484 DumpOpenRegistryHandle: 3 user
registry Handles leaked from
\Registry\User\S-1-5-21-1417001333-1677128483-1801674531-1002_Classes
USERENV(c8.b0) 15:00:12:578 UnloadUserProfile: Failed to
flush the current user key, error = 1016

The last one, with error = 1016, is by far the most common
log entry.

You can try stopping the Spooler Service prior to
logoff/shutdown. That helps in some cases. You can
write to rcaron [at] microsoft.com and ask for a
developmental utility UPHclean that seems to work
well. There was also a specific W2K HotFix that cause
this problem. It may be 329170 (but bot certain).

Thanks for the up-to-date address for Robin Caron. All
other references I could find to UPHClean mentioned her
now-defunct Hotmail account.

Yes. But check your account's HKCU too (ntuser.dat)
just in case.

Check how, exactly?

One seeming anomaly: The Gnu "file" command (part of
Cygwin) reports different file types for my ntuser.dat
files. It identifies my ntuser.dat file as "executable",
which seems odd. It identifies the other three ntuser.dat
files as "Windows NT Registry file". (The "file" command
looks for magic numbers and other content patterns to make
its determination). Although there are only two ".LOG"
counterparts, they show the same misidentification pattern.

That misidentification may be spurious (the signatures used
by "file" may not be adequately specified to properly
identify all registry files) or the hive file(s) could be
corrupt somehow. However, if that file were not mostly
intact, it seems I would have much bigger registry problems
than I do. Perhaps not...

Can ntuser.dat be repaired? Are their tools that will
diangose that file's integrity? Does chkreg.exe process
user hives, too, or only system ones. Absent tools to
diagnose and / or repair an ntuser.dat file, what's to be done?

Any chance you are growing the total registry size
beyond the "Maximum" setting? System Properties,
Advanced, Performance Options, Change?

No. I checked that already.

Another thing, those errors do not correspond
(in terms of dates) to the latest failures to
retain registry modifications. There are only
three of them: One is from March, the other two
date back a day or so. Nonetheless, presumably
they're relevant clues to what's still happening now.



That's a good question. This is essentially a
single-user machine, though I keep a separate
administrator account even though the account I
use on a daily basis has full administrative
privileges.

Try the alternate account. If that works it may be
that your (primary) account registry is somehow corrupt.
In that case you may >need to rebuild it. This assumes
that the problem is in <account>\ntuser.dat and not
<system>\SOFTWARE though. I may have >missed it, but
am assuming HKCU and not HKLM\Software...

[ ]
As I said, several applications, including Windows
Explorer's record of desktop icon positions, are
lost when this symptom occurs, which is frequently.
Thanks for pointing me in the right direction.

I don't know that I have. Just some ideas. I have not
personally suffered from the condition there. And I
assume you have used up-to-date Anti-Virus, A-Trojan,
and A-Spyware/Adware tools. And that no tools are
"locking" the registry on purpose.

Yes, my Norton firewall and virus tools are kept up-to-date
with each Wednesday's LiveUpdate. Likewise for MS-supplied
patches.


Thanks again for all your help.

Randall Schulz
 
[ some large snips ... ]
There appear to be many more related messages in
"\WINNT\Debug\UserMode\userenv.log":

Not surprising. There are lots of (rather cryptic) messages there.
I cannot analyze them reliably in most cases.
USERENV(c8.b0) 08:49:56:484 MyRegUnLoadKey: Hive unload for
S-1-5-21-1417001333-1677128483-1801674531-1002_Classes
failed due to open registry key. Windows will try
unloading the registry hive once a second for the next 60
seconds (max).
USERENV(c8.b0) 08:50:56:484 MyRegUnLoadKey: Windows was not
able to unload the registry hive.
USERENV(c8.b0) 08:50:56:484 MyRegUnLoadKey: Failed to
unmount hive 5
USERENV(c8.b0) 08:50:56:484 UnLoadClassHive: failed to
unload classes key with 5
USERENV(c8.b0) 08:50:56:484 DumpOpenRegistryHandle: 3 user
registry Handles leaked from
\Registry\User\S-1-5-21-1417001333-1677128483-1801674531-1002 _Classes
USERENV(c8.b0) 15:00:12:578 UnloadUserProfile: Failed to
flush the current user key, error = 1016

The last one, with error = 1016, is by far the most common
log entry.

Hoping someone with more userenv.log experience can comment on these.

[ ]
Thanks for the up-to-date address for Robin Caron. All
other references I could find to UPHClean mentioned her
now-defunct Hotmail account.

I lifted that address from the Readme for ver. 1.2.0.7
Hope it's good.

[ ]
Check how, exactly?

You were looking at file ACLs on the System hive files, yes? And
they were likely Administrators:FULL, SYSTEM:FULL. The User profile
hive files (ntuser.dat and usrclass.dat) typically have file ACLs the
same but also with the UserName:FULL. Then there are the registry
ACL's "inside" the hive. These are what you would see looking at
HKCU with regedt32.exe as Permissions. This I think though is off
track for the problem perhaps. Unless you have purposely changed
them before.
One seeming anomaly: The Gnu "file" command (part of
Cygwin) reports different file types for my ntuser.dat
files. It identifies my ntuser.dat file as "executable",
which seems odd. It identifies the other three ntuser.dat
files as "Windows NT Registry file". (The "file" command
looks for magic numbers and other content patterns to make
its determination). Although there are only two ".LOG"
counterparts, they show the same misidentification pattern.

Hmm. Not familiar with that, but likely it's the difference between
static hive files (other accounts) and an active (loaded and locked)
one for your logon account.

[ ]
Can ntuser.dat be repaired? Are their tools that will
diangose that file's integrity? Does chkreg.exe process
user hives, too, or only system ones. Absent tools to
diagnose and / or repair an ntuser.dat file, what's to be done?

"Repaired" implies there is a known and detectable error of some
kind. I do not know if we really know that yet. No reliable tools I
know of. Don't know CHKREG.EXE but understand it is rather a "tool
of last resort" in any case. The usual solution for a provable
corrupt profile hive is to blow it away and rebuild it. But don't do
that yet, or at least use another logon to preserve the old one
first. Could be a lot of work rebuilding.

It is possible that there is nothing wrong in that profile. It could
be something else entirely. I have no way of knowing.
[ ]

Did you use another account? Any trouble? If no then _I_ would be
thinking of rebuilding the problem profile. FWIW and lacking any new
information or other feedback. Recall that your first post was only
just over 1 day ago. Other knowledgeable posters may drop into this
thread yet. :-)
 
[ some large snips ... ]
There appear to be many more related messages in
"\WINNT\Debug\UserMode\userenv.log":

Not surprising. There are lots of (rather cryptic) messages there.
I cannot analyze them reliably in most cases.
USERENV(c8.b0) 08:49:56:484 MyRegUnLoadKey: Hive unload for
S-1-5-21-1417001333-1677128483-1801674531-1002_Classes
failed due to open registry key. Windows will try
unloading the registry hive once a second for the next 60
seconds (max).
USERENV(c8.b0) 08:50:56:484 MyRegUnLoadKey: Windows was not
able to unload the registry hive.
USERENV(c8.b0) 08:50:56:484 MyRegUnLoadKey: Failed to
unmount hive 5
USERENV(c8.b0) 08:50:56:484 UnLoadClassHive: failed to
unload classes key with 5
USERENV(c8.b0) 08:50:56:484 DumpOpenRegistryHandle: 3 user
registry Handles leaked from
\Registry\User\S-1-5-21-1417001333-1677128483-1801674531-1002 _Classes
USERENV(c8.b0) 15:00:12:578 UnloadUserProfile: Failed to
flush the current user key, error = 1016

The last one, with error = 1016, is by far the most common
log entry.

Hoping someone with more userenv.log experience can comment on these.

[ ]
Thanks for the up-to-date address for Robin Caron. All
other references I could find to UPHClean mentioned her
now-defunct Hotmail account.

I lifted that address from the Readme for ver. 1.2.0.7
Hope it's good.

[ ]
Check how, exactly?

You were looking at file ACLs on the System hive files, yes? And
they were likely Administrators:FULL, SYSTEM:FULL. The User profile
hive files (ntuser.dat and usrclass.dat) typically have file ACLs the
same but also with the UserName:FULL. Then there are the registry
ACL's "inside" the hive. These are what you would see looking at
HKCU with regedt32.exe as Permissions. This I think though is off
track for the problem perhaps. Unless you have purposely changed
them before.
One seeming anomaly: The Gnu "file" command (part of
Cygwin) reports different file types for my ntuser.dat
files. It identifies my ntuser.dat file as "executable",
which seems odd. It identifies the other three ntuser.dat
files as "Windows NT Registry file". (The "file" command
looks for magic numbers and other content patterns to make
its determination). Although there are only two ".LOG"
counterparts, they show the same misidentification pattern.

Hmm. Not familiar with that, but likely it's the difference between
static hive files (other accounts) and an active (loaded and locked)
one for your logon account.

[ ]
Can ntuser.dat be repaired? Are their tools that will
diangose that file's integrity? Does chkreg.exe process
user hives, too, or only system ones. Absent tools to
diagnose and / or repair an ntuser.dat file, what's to be done?

"Repaired" implies there is a known and detectable error of some
kind. I do not know if we really know that yet. No reliable tools I
know of. Don't know CHKREG.EXE but understand it is rather a "tool
of last resort" in any case. The usual solution for a provable
corrupt profile hive is to blow it away and rebuild it. But don't do
that yet, or at least use another logon to preserve the old one
first. Could be a lot of work rebuilding.

It is possible that there is nothing wrong in that profile. It could
be something else entirely. I have no way of knowing.
[ ]

Did you use another account? Any trouble? If no then _I_ would be
thinking of rebuilding the problem profile. FWIW and lacking any new
information or other feedback. Recall that your first post was only
just over 1 day ago. Other knowledgeable posters may drop into this
thread yet. :-)
 
Mark,

I think I may have found the problem. Tell me if you think
this makes sense:

I was having trouble with the on-motherboard audio
circuitry in my system (AC'97 based on Realtek audio
chips). So I bought a new sound card. When I installed it,
I manually (via the Management Console) disabled the
drivers for the old audio. I left all of the software for
that sound support installed. It turns out this software
installs an auto-run program (SOUNDMAN.EXE) which continues
to run even when the drivers are disabled.

So earlier today, I uninstalled the Realtek software and so
far have been able to reboot twice without losing my
registry settings.

So is it possible or likely that that program, because it
could not access its driver and possibly was not written as
robustly as it should have been (and / or I violated the
assumptions under which it was written by disabling the
drivers), failed to terminate cleanly and thus interfered
with the registry saving portion of system shutdown?

On thing that put me on to that program was the fact that
the Sysinternals Process Explorer suggested that that
process was using the registry.

We'll see. I'll try more reboots before declaring this
problem solved.

Randall Schulz
 
Mark,

I think I may have found the problem. Tell me if you think
this makes sense:

I was having trouble with the on-motherboard audio
circuitry in my system (AC'97 based on Realtek audio
chips). So I bought a new sound card. When I installed it,
I manually (via the Management Console) disabled the
drivers for the old audio. I left all of the software for
that sound support installed. It turns out this software
installs an auto-run program (SOUNDMAN.EXE) which continues
to run even when the drivers are disabled.

So earlier today, I uninstalled the Realtek software and so
far have been able to reboot twice without losing my
registry settings.

So is it possible or likely that that program, because it
could not access its driver and possibly was not written as
robustly as it should have been (and / or I violated the
assumptions under which it was written by disabling the
drivers), failed to terminate cleanly and thus interfered
with the registry saving portion of system shutdown?

On thing that put me on to that program was the fact that
the Sysinternals Process Explorer suggested that that
process was using the registry.

We'll see. I'll try more reboots before declaring this
problem solved.

Randall Schulz
 
In said:
Mark,

I think I may have found the problem. Tell me if you think
this makes sense:

I was having trouble with the on-motherboard audio
circuitry in my system (AC'97 based on Realtek audio
chips). So I bought a new sound card. When I installed it,
I manually (via the Management Console) disabled the
drivers for the old audio. I left all of the software for
that sound support installed. It turns out this software
installs an auto-run program (SOUNDMAN.EXE) which continues
to run even when the drivers are disabled.

So earlier today, I uninstalled the Realtek software and so
far have been able to reboot twice without losing my
registry settings.

So is it possible or likely that that program, because it
could not access its driver and possibly was not written as
robustly as it should have been (and / or I violated the
assumptions under which it was written by disabling the
drivers), failed to terminate cleanly and thus interfered
with the registry saving portion of system shutdown?

On thing that put me on to that program was the fact that
the Sysinternals Process Explorer suggested that that
process was using the registry.

We'll see. I'll try more reboots before declaring this
problem solved.

Phew. Anything is possible. :-)
Your scenario certainly sounds plausible. And appears to be
supported empirically... Really should officially un-install and/or
remove Devices no longer used/present as a general rule. This
orphaned soundman.exe could well have been the culprit. Hope you did
indeed find the cause.

Good to hear of PROCEXP.EXE as I appreciate and like most of the
Sysinternals tools. Great research tools.

Please post again Randall with "that was it!" or something. :-)
 
In said:
Mark,

I think I may have found the problem. Tell me if you think
this makes sense:

I was having trouble with the on-motherboard audio
circuitry in my system (AC'97 based on Realtek audio
chips). So I bought a new sound card. When I installed it,
I manually (via the Management Console) disabled the
drivers for the old audio. I left all of the software for
that sound support installed. It turns out this software
installs an auto-run program (SOUNDMAN.EXE) which continues
to run even when the drivers are disabled.

So earlier today, I uninstalled the Realtek software and so
far have been able to reboot twice without losing my
registry settings.

So is it possible or likely that that program, because it
could not access its driver and possibly was not written as
robustly as it should have been (and / or I violated the
assumptions under which it was written by disabling the
drivers), failed to terminate cleanly and thus interfered
with the registry saving portion of system shutdown?

On thing that put me on to that program was the fact that
the Sysinternals Process Explorer suggested that that
process was using the registry.

We'll see. I'll try more reboots before declaring this
problem solved.

Phew. Anything is possible. :-)
Your scenario certainly sounds plausible. And appears to be
supported empirically... Really should officially un-install and/or
remove Devices no longer used/present as a general rule. This
orphaned soundman.exe could well have been the culprit. Hope you did
indeed find the cause.

Good to hear of PROCEXP.EXE as I appreciate and like most of the
Sysinternals tools. Great research tools.

Please post again Randall with "that was it!" or something. :-)
 
Mark,
-----Original Message-----
Phew. Anything is possible. :-)
Your scenario certainly sounds plausible. And appears
to be supported empirically... Really should
officially un-install and/or remove Devices no
longer used/present as a general rule. This orphaned
soundman.exe could well have been the culprit. Hope
you did indeed find the cause.

Yeah, I know I should remove device software when the
hardware is removed. I was trying to be "conservative" in
case I had problems with the new hardware.

Good to hear of PROCEXP.EXE as I appreciate
and like most of the Sysinternals tools.
Great research tools.

Please post again Randall with "that was it!"
or something. :-)


Robin sent me UPHClean, though perhaps it won't tell me
anything any more.

I've rebooted again (3rd time, now) and still changes are
being remembered.

I forgot to mention in my previous post that the problem
began around the time I got the new sound card, though I
cannot exactly pinpoint the first occurrence of the
symptom, and I was adding bunches of hardware and software
to the system at the time (also unwise, I suppose).

The issue of the print queue manager (or whatever it's
called) possibly being implicated in this problem led me to
wonder if the symptom was only occurring if I'd printed
since the last reboot. So this last time I did some
printing before rebooting and still all's OK.

Keep your fingers crossed for me, OK?

Randall Schulz
 
Back
Top