Windows 7 crash

[Jeff]

Despite using Windows PCs for many years I have never seen a "blue
screen of death" on my PCs. However one of the elder people I help out
had one last night. I got her out of it by booting into safe mode (F8)
and then into regular mode. When it booted into regular mode I noticed
that the screen showed she was in the middle of a Windows Critical
Update when she crashed during the night. Perhaps there was a power
failure (none of her clocks showed it to be the case) or something
happened to the internet connection. I don't know.

I checked out her system logs and 2 errors jumped out at me:

The following boot-start or system-start driver(s) failed to load:
AFD
aswRdr

DCOM got error "1084" attempting to start the service ShellHWDetection
with arguments "" in order to run the server:
{DD522ACC-F821-461A-A407-50B198B896DC}

Hopefully this will not happen again but do these errors suggest what
may have happened?

Anything to do?

Jeff

 

[Char Jackson]

Despite using Windows PCs for many years I have never seen a "blue
screen of death" on my PCs. However one of the elder people I help out
had one last night. I got her out of it by booting into safe mode (F8)
and then into regular mode. When it booted into regular mode I noticed
that the screen showed she was in the middle of a Windows Critical
Update when she crashed during the night. Perhaps there was a power
failure (none of her clocks showed it to be the case) or something
happened to the internet connection. I don't know.

I checked out her system logs and 2 errors jumped out at me:

The following boot-start or system-start driver(s) failed to load:
AFD
aswRdr

DCOM got error "1084" attempting to start the service ShellHWDetection
with arguments "" in order to run the server:
{DD522ACC-F821-461A-A407-50B198B896DC}

Hopefully this will not happen again but do these errors suggest what
may have happened?

Anything to do?

You're much better off taking a look at the actual crash dump with
Nirsoft's BlueScreenView. Get it here:
<http://www.nirsoft.net/utils/blue_screen_view.html>

 

[charlie]

Despite using Windows PCs for many years I have never seen a "blue
screen of death" on my PCs. However one of the elder people I help out
had one last night. I got her out of it by booting into safe mode (F8)
and then into regular mode. When it booted into regular mode I noticed
that the screen showed she was in the middle of a Windows Critical
Update when she crashed during the night. Perhaps there was a power
failure (none of her clocks showed it to be the case) or something
happened to the internet connection. I don't know.

I checked out her system logs and 2 errors jumped out at me:

The following boot-start or system-start driver(s) failed to load:
AFD
aswRdr

DCOM got error "1084" attempting to start the service ShellHWDetection
with arguments "" in order to run the server:
{DD522ACC-F821-461A-A407-50B198B896DC}

Hopefully this will not happen again but do these errors suggest what
may have happened?

Anything to do?

Jeff

If an update was interrupted, all kinds of strange symptoms can result.
Generally, if the system will run, I'll look at the update history, and
see if anything jumps out. If this is the first "blue screen" you've
had, you're either a bit new to the game or extremely lucky. In a few
cases, reversing an update or group of updates is needed, followed by a
selective one by one update. Another one is that occasionally, on some
update runs, a troublesome update can be manually deferred, and the
others in a group finished, then followed by the troublesome one.

Windows is also, to some extent, self repairing. (With a lot of
caveats.) I don't get too concerned about things that go "bump in the
night", unless they repeat.

It looks like the error involved Avast. Virus checkers and bona fide
windows updates sometimes have problems.
It can get disconcerting, due to the existence of malware that
spoofs windows updates.

 

[Jeff]

Despite using Windows PCs for many years I have never seen a "blue
screen of death" on my PCs. However one of the elder people I help out
had one last night. I got her out of it by booting into safe mode (F8)
and then into regular mode. When it booted into regular mode I noticed
that the screen showed she was in the middle of a Windows Critical
Update when she crashed during the night. Perhaps there was a power
failure (none of her clocks showed it to be the case) or something
happened to the internet connection. I don't know.

I checked out her system logs and 2 errors jumped out at me:

The following boot-start or system-start driver(s) failed to load:
AFD
aswRdr

DCOM got error "1084" attempting to start the service ShellHWDetection
with arguments "" in order to run the server:
{DD522ACC-F821-461A-A407-50B198B896DC}

Hopefully this will not happen again but do these errors suggest what
may have happened?

Anything to do?

Jeff

Thank yu both.

 

[Yousuf Khan]

Despite using Windows PCs for many years I have never seen a "blue
screen of death" on my PCs. However one of the elder people I help out
had one last night. I got her out of it by booting into safe mode (F8)
and then into regular mode. When it booted into regular mode I noticed
that the screen showed she was in the middle of a Windows Critical
Update when she crashed during the night. Perhaps there was a power
failure (none of her clocks showed it to be the case) or something
happened to the internet connection. I don't know.

In addition to Char Jackson's suggestion to download BlueScreenView,
which I also highly recommend, I would also suggest you create a custom
view on her machine's Event Viewer to show you all of the times that the
machine rebooted. Or you can download a ready-built Event Viewer filter,
like mine. You can download it from my Skydrive and install inside Event
Viewer.

https://skydrive.live.com/?cid=56f77fa4ad5dbacf&id=56F77FA4AD5DBACF!107#

This custom view will tell you both when the machine went down, as well
as when it came back up. All other events will either occur before the
down event, or after the up event. This aids in determining all of the
machine events that took place that led to the machine going down, or
immediately after reboot as the machine was coming back up.


Yousuf Khan

 

[Jeff]

In addition to Char Jackson's suggestion to download BlueScreenView,
which I also highly recommend, I would also suggest you create a custom
view on her machine's Event Viewer to show you all of the times that the
machine rebooted. Or you can download a ready-built Event Viewer filter,
like mine. You can download it from my Skydrive and install inside Event
Viewer.

https://skydrive.live.com/?cid=56f77fa4ad5dbacf&id=56F77FA4AD5DBACF!107#

This custom view will tell you both when the machine went down, as well
as when it came back up. All other events will either occur before the
down event, or after the up event. This aids in determining all of the
machine events that took place that led to the machine going down, or
immediately after reboot as the machine was coming back up.


Yousuf Khan

Thank you.
Jeff

 

[Jeff]

Despite using Windows PCs for many years I have never seen a "blue
screen of death" on my PCs. However one of the elder people I help out
had one last night. I got her out of it by booting into safe mode (F8)
and then into regular mode. When it booted into regular mode I noticed
that the screen showed she was in the middle of a Windows Critical
Update when she crashed during the night. Perhaps there was a power
failure (none of her clocks showed it to be the case) or something
happened to the internet connection. I don't know.

I checked out her system logs and 2 errors jumped out at me:

The following boot-start or system-start driver(s) failed to load:
AFD
aswRdr

DCOM got error "1084" attempting to start the service ShellHWDetection
with arguments "" in order to run the server:
{DD522ACC-F821-461A-A407-50B198B896DC}

Hopefully this will not happen again but do these errors suggest what
may have happened?

Anything to do?

Jeff

I should not have boasted about not having to face blue screens because
I just got one.
Here is the sad story:
For a couple of days I have been having problems with shutdown in my
Windows 7 64 bit new laptop system. The shut down proceeds normally till
I get the "Shutting down" part which then continues indefinitely without
every finishing until I press the power button.
I did not install any new drivers so I do not think that is the problem.

I tried shutting down in safe mode but the problem persists.

So, I decided to restore to a point before the crashes started. Here is
where the crash appears. I get warning about not doing anything until
restore has completed and shutdown starts and then almost immediately
the system crashes with the blue screen.

I tried restoring again: same thing.

I then tried restoring in safe mode -> same crash.

All in all 3 crashes following each other during the shutdown part.

I used Nirsoft's BlueScreenView but cannot tell much from the report
which essentially says:

Bug Check String: Critical_Object_termination
Bug Check Code: 0x000000f4
various Parameters
Caused by Driver: ntoskrnl.exe
Caused by address: ntoskrnl.exe+7f1c0
File Description: NT Kerne & System
File Version 6.1.7601.17835 [win7sp1_gdr.120503-2030]
Processor x64
Crash Address ntoskrnl.exe+7fic0

Since the elderly lady I help got her crash *during* her automatic
"Windows 7 Critical update" and I got mine in the last couple of days
after the last Windows update, maybe the crashes are a result of
something in the last update?

In any case, what should I do?

Thanks.

Jeff

 

[Joe Morris]

For a couple of days I have been having problems with shutdown in my
Windows 7 64 bit new laptop system. The shut down proceeds normally till I
get the "Shutting down" part which then continues indefinitely without
every finishing until I press the power button.
I did not install any new drivers so I do not think that is the problem.

I used Nirsoft's BlueScreenView but cannot tell much from the report which
essentially says:

Bug Check String: Critical_Object_termination
Bug Check Code: 0x000000f4
various Parameters
Caused by Driver: ntoskrnl.exe
Caused by address: ntoskrnl.exe+7f1c0
File Description: NT Kerne & System
File Version 6.1.7601.17835 [win7sp1_gdr.120503-2030]
Processor x64
Crash Address ntoskrnl.exe+7fic0

Stop code F4 isn't particularly specific; all it tells you is that something
critical to the survival of the system has failed. In your case "ntoskrnl"
may or may not be related to the problem. Incidentally, your report shows
the current build (17835); it was delivered as part of MS12-042, which was
released in June.

Any change to code *or data* that is used by the kernel might be the cause
of this BSOD; it doesn't have to be a Windows update. For example, if
you're using a non-Microsoft AV program it might have quietly downloaded a
buggy signature file, or even a program update. Ditto for device drivers
written by some vendors.

And it's also possible that the latest change (Microsoft patch, AV update,
whatever) triggered the failure, but wasn't where the broken code can be
found. About 15 months ago I had a really nasty problem at my POE where
users' systems died, in several cases, requiring reimaging. What happened
was that buggy code had been loaded some time well before the failure, but
its errors (probably wild stores into memory) didn't happen to hit critical
data. When a Microsoft update to .NET changed memory layout, the memory
location being corrupted became a critical field and the systems died a
messy death. Making the diagnosis harder, different users had very
different symptoms.

Think of it as an IED planted (intentionally or not) in the logical roadbed.

(This is one reason that we disable automatic updating in all products we
support on user machines. Once we identified the Windows update as the
trigger we pulled it from distribution and resumed its distribution only
after removing the actual offender from all systems.)

Joe

 

[Jeff]

For a couple of days I have been having problems with shutdown in my
Windows 7 64 bit new laptop system. The shut down proceeds normally till I
get the "Shutting down" part which then continues indefinitely without
every finishing until I press the power button.
I did not install any new drivers so I do not think that is the problem.

I used Nirsoft's BlueScreenView but cannot tell much from the report which
essentially says:

Bug Check String: Critical_Object_termination
Bug Check Code: 0x000000f4
various Parameters
Caused by Driver: ntoskrnl.exe
Caused by address: ntoskrnl.exe+7f1c0
File Description: NT Kerne & System
File Version 6.1.7601.17835 [win7sp1_gdr.120503-2030]
Processor x64
Crash Address ntoskrnl.exe+7fic0

Stop code F4 isn't particularly specific; all it tells you is that something
critical to the survival of the system has failed. In your case "ntoskrnl"
may or may not be related to the problem. Incidentally, your report shows
the current build (17835); it was delivered as part of MS12-042, which was
released in June.

Any change to code *or data* that is used by the kernel might be the cause
of this BSOD; it doesn't have to be a Windows update. For example, if
you're using a non-Microsoft AV program it might have quietly downloaded a
buggy signature file, or even a program update. Ditto for device drivers
written by some vendors.

And it's also possible that the latest change (Microsoft patch, AV update,
whatever) triggered the failure, but wasn't where the broken code can be
found. About 15 months ago I had a really nasty problem at my POE where
users' systems died, in several cases, requiring reimaging. What happened
was that buggy code had been loaded some time well before the failure, but
its errors (probably wild stores into memory) didn't happen to hit critical
data. When a Microsoft update to .NET changed memory layout, the memory
location being corrupted became a critical field and the systems died a
messy death. Making the diagnosis harder, different users had very
different symptoms.

Think of it as an IED planted (intentionally or not) in the logical roadbed.

(This is one reason that we disable automatic updating in all products we
support on user machines. Once we identified the Windows update as the
trigger we pulled it from distribution and resumed its distribution only
after removing the actual offender from all systems.)

Joe

I hear you.

I decided to restore the OS partition (C from an image done 3 days ago
before all the problems started. I don't do automatic Windows updates. I
ask Windows to download them and then notify me but I also tend to
install them very sson after the sytem tells me about it.

As I think back over the past day or two I now think the problems may
have stated after I used Revo Uninstall to uninstall something. Revo
goes much further than just a standard uninstall and I suspect it my
have done more than it should in its cleaning zeal. (May also later get
rid of Revo itself which I think has done something like this before)

Wish me luck.

 

[Jeff]

For a couple of days I have been having problems with shutdown in my
Windows 7 64 bit new laptop system. The shut down proceeds normally
till I
get the "Shutting down" part which then continues indefinitely without
every finishing until I press the power button.
I did not install any new drivers so I do not think that is the problem.

I used Nirsoft's BlueScreenView but cannot tell much from the report
which
essentially says:

Bug Check String: Critical_Object_termination
Bug Check Code: 0x000000f4
various Parameters
Caused by Driver: ntoskrnl.exe
Caused by address: ntoskrnl.exe+7f1c0
File Description: NT Kerne & System
File Version 6.1.7601.17835 [win7sp1_gdr.120503-2030]
Processor x64
Crash Address ntoskrnl.exe+7fic0

Stop code F4 isn't particularly specific; all it tells you is that
something
critical to the survival of the system has failed. In your case
"ntoskrnl"
may or may not be related to the problem. Incidentally, your report
shows
the current build (17835); it was delivered as part of MS12-042, which
was
released in June.

Any change to code *or data* that is used by the kernel might be the
cause
of this BSOD; it doesn't have to be a Windows update. For example, if
you're using a non-Microsoft AV program it might have quietly
downloaded a
buggy signature file, or even a program update. Ditto for device drivers
written by some vendors.

And it's also possible that the latest change (Microsoft patch, AV
update,
whatever) triggered the failure, but wasn't where the broken code can be
found. About 15 months ago I had a really nasty problem at my POE where
users' systems died, in several cases, requiring reimaging. What
happened
was that buggy code had been loaded some time well before the failure,
but
its errors (probably wild stores into memory) didn't happen to hit
critical
data. When a Microsoft update to .NET changed memory layout, the memory
location being corrupted became a critical field and the systems died a
messy death. Making the diagnosis harder, different users had very
different symptoms.

Think of it as an IED planted (intentionally or not) in the logical
roadbed.

(This is one reason that we disable automatic updating in all products we
support on user machines. Once we identified the Windows update as the
trigger we pulled it from distribution and resumed its distribution only
after removing the actual offender from all systems.)

Joe

I hear you.

I decided to restore the OS partition (C from an image done 3 days ago
before all the problems started. I don't do automatic Windows updates. I
ask Windows to download them and then notify me but I also tend to
install them very sson after the sytem tells me about it.

As I think back over the past day or two I now think the problems may
have stated after I used Revo Uninstall to uninstall something. Revo
goes much further than just a standard uninstall and I suspect it my
have done more than it should in its cleaning zeal. (May also later get
rid of Revo itself which I think has done something like this before)

Wish me luck.

Now this is ironic.

I decided to restore an image I had from 3 days ago. So I first made a
backup of the current situation and then restored the 3 day old one.
Guess what? The shutdown problem is still here. Will still not shut down
completely!
Because this is a new laptop I don't have earlier backups but have
installed a lot of software and therefore do not want to go back to the
factory state. Darn!

 

[Paul]

For a couple of days I have been having problems with shutdown in my
Windows 7 64 bit new laptop system. The shut down proceeds normally
till I
get the "Shutting down" part which then continues indefinitely without
every finishing until I press the power button.
I did not install any new drivers so I do not think that is the
problem.

I used Nirsoft's BlueScreenView but cannot tell much from the report
which
essentially says:

Bug Check String: Critical_Object_termination
Bug Check Code: 0x000000f4
various Parameters
Caused by Driver: ntoskrnl.exe
Caused by address: ntoskrnl.exe+7f1c0
File Description: NT Kerne & System
File Version 6.1.7601.17835 [win7sp1_gdr.120503-2030]
Processor x64
Crash Address ntoskrnl.exe+7fic0

Stop code F4 isn't particularly specific; all it tells you is that
something
critical to the survival of the system has failed. In your case
"ntoskrnl"
may or may not be related to the problem. Incidentally, your report
shows
the current build (17835); it was delivered as part of MS12-042, which
was
released in June.

Any change to code *or data* that is used by the kernel might be the
cause
of this BSOD; it doesn't have to be a Windows update. For example, if
you're using a non-Microsoft AV program it might have quietly
downloaded a
buggy signature file, or even a program update. Ditto for device
drivers
written by some vendors.

And it's also possible that the latest change (Microsoft patch, AV
update,
whatever) triggered the failure, but wasn't where the broken code can be
found. About 15 months ago I had a really nasty problem at my POE where
users' systems died, in several cases, requiring reimaging. What
happened
was that buggy code had been loaded some time well before the failure,
but
its errors (probably wild stores into memory) didn't happen to hit
critical
data. When a Microsoft update to .NET changed memory layout, the memory
location being corrupted became a critical field and the systems died a
messy death. Making the diagnosis harder, different users had very
different symptoms.

Think of it as an IED planted (intentionally or not) in the logical
roadbed.

(This is one reason that we disable automatic updating in all
products we
support on user machines. Once we identified the Windows update as the
trigger we pulled it from distribution and resumed its distribution only
after removing the actual offender from all systems.)

Joe

I hear you.

I decided to restore the OS partition (C from an image done 3 days ago
before all the problems started. I don't do automatic Windows updates. I
ask Windows to download them and then notify me but I also tend to
install them very sson after the sytem tells me about it.

As I think back over the past day or two I now think the problems may
have stated after I used Revo Uninstall to uninstall something. Revo
goes much further than just a standard uninstall and I suspect it my
have done more than it should in its cleaning zeal. (May also later get
rid of Revo itself which I think has done something like this before)

Wish me luck.

Now this is ironic.

I decided to restore an image I had from 3 days ago. So I first made a
backup of the current situation and then restored the 3 day old one.
Guess what? The shutdown problem is still here. Will still not shut down
completely!
Because this is a new laptop I don't have earlier backups but have
installed a lot of software and therefore do not want to go back to the
factory state. Darn!

In the example here, the respondent was able to determine the critical object
was "csrss". Which suggests, however that dump was read, it had a little additional
information to give.

http://www.sevenforums.com/crashes-debugging/116679-bsod-critical_object_termination-error.html

http://en.wikipedia.org/wiki/Client/Server_Runtime_Subsystem

There's probably a couple of things that rate as critical, and I presume
the kernel is detecting this, in the interest of shutting down a
compromised system.

Sure, it could be a memory error (memory failure), but what are the odds it
would hit just the right place ?

Other alternatives, would be to test with a Linux LiveCD (which frequently includes
memtest as a boot time option), and you could test whether shutdown there
is "normal" or not. I'd only bother with that, if you had the Linux LiveCD
already, rather than waste the time on a new download now.

Paul

 

[Jeff]

On 8/19/2012 10:40 PM, Joe Morris wrote:

For a couple of days I have been having problems with shutdown in my
Windows 7 64 bit new laptop system. The shut down proceeds normally
till I
get the "Shutting down" part which then continues indefinitely without
every finishing until I press the power button.
I did not install any new drivers so I do not think that is the
problem.

I used Nirsoft's BlueScreenView but cannot tell much from the report
which
essentially says:

Bug Check String: Critical_Object_termination
Bug Check Code: 0x000000f4
various Parameters
Caused by Driver: ntoskrnl.exe
Caused by address: ntoskrnl.exe+7f1c0
File Description: NT Kerne & System
File Version 6.1.7601.17835 [win7sp1_gdr.120503-2030]
Processor x64
Crash Address ntoskrnl.exe+7fic0

Stop code F4 isn't particularly specific; all it tells you is that
something
critical to the survival of the system has failed. In your case
"ntoskrnl"
may or may not be related to the problem. Incidentally, your report
shows
the current build (17835); it was delivered as part of MS12-042, which
was
released in June.

Any change to code *or data* that is used by the kernel might be the
cause
of this BSOD; it doesn't have to be a Windows update. For example, if
you're using a non-Microsoft AV program it might have quietly
downloaded a
buggy signature file, or even a program update. Ditto for device
drivers
written by some vendors.

And it's also possible that the latest change (Microsoft patch, AV
update,
whatever) triggered the failure, but wasn't where the broken code
can be
found. About 15 months ago I had a really nasty problem at my POE
where
users' systems died, in several cases, requiring reimaging. What
happened
was that buggy code had been loaded some time well before the failure,
but
its errors (probably wild stores into memory) didn't happen to hit
critical
data. When a Microsoft update to .NET changed memory layout, the
memory
location being corrupted became a critical field and the systems died a
messy death. Making the diagnosis harder, different users had very
different symptoms.

Think of it as an IED planted (intentionally or not) in the logical
roadbed.

(This is one reason that we disable automatic updating in all
products we
support on user machines. Once we identified the Windows update as the
trigger we pulled it from distribution and resumed its distribution
only
after removing the actual offender from all systems.)

Joe


I hear you.

I decided to restore the OS partition (C from an image done 3 days ago
before all the problems started. I don't do automatic Windows updates. I
ask Windows to download them and then notify me but I also tend to
install them very sson after the sytem tells me about it.

As I think back over the past day or two I now think the problems may
have stated after I used Revo Uninstall to uninstall something. Revo
goes much further than just a standard uninstall and I suspect it my
have done more than it should in its cleaning zeal. (May also later get
rid of Revo itself which I think has done something like this before)

Wish me luck.

Now this is ironic.

I decided to restore an image I had from 3 days ago. So I first made a
backup of the current situation and then restored the 3 day old one.
Guess what? The shutdown problem is still here. Will still not shut
down completely!
Because this is a new laptop I don't have earlier backups but have
installed a lot of software and therefore do not want to go back to
the factory state. Darn!

In the example here, the respondent was able to determine the critical
object
was "csrss". Which suggests, however that dump was read, it had a little
additional
information to give.

http://www.sevenforums.com/crashes-debugging/116679-bsod-critical_object_termination-error.html


http://en.wikipedia.org/wiki/Client/Server_Runtime_Subsystem

There's probably a couple of things that rate as critical, and I presume
the kernel is detecting this, in the interest of shutting down a
compromised system.

Sure, it could be a memory error (memory failure), but what are the odds it
would hit just the right place ?

Other alternatives, would be to test with a Linux LiveCD (which
frequently includes
memtest as a boot time option), and you could test whether shutdown there
is "normal" or not. I'd only bother with that, if you had the Linux LiveCD
already, rather than waste the time on a new download now.

Paul

I have several linux live CDs. Will try tomorrow.
Shame there is not a "repair" mode to W7.
I already checked the disk surface and it is fine and also ran a virus
heck with no problem. What a pain!

 

[Paul]

On 8/19/2012 10:54 PM, (e-mail address removed) wrote:
On 8/19/2012 10:40 PM, Joe Morris wrote:

For a couple of days I have been having problems with shutdown in my
Windows 7 64 bit new laptop system. The shut down proceeds normally
till I
get the "Shutting down" part which then continues indefinitely
without
every finishing until I press the power button.
I did not install any new drivers so I do not think that is the
problem.

I used Nirsoft's BlueScreenView but cannot tell much from the report
which
essentially says:

Bug Check String: Critical_Object_termination
Bug Check Code: 0x000000f4
various Parameters
Caused by Driver: ntoskrnl.exe
Caused by address: ntoskrnl.exe+7f1c0
File Description: NT Kerne & System
File Version 6.1.7601.17835 [win7sp1_gdr.120503-2030]
Processor x64
Crash Address ntoskrnl.exe+7fic0

Stop code F4 isn't particularly specific; all it tells you is that
something
critical to the survival of the system has failed. In your case
"ntoskrnl"
may or may not be related to the problem. Incidentally, your report
shows
the current build (17835); it was delivered as part of MS12-042, which
was
released in June.

Any change to code *or data* that is used by the kernel might be the
cause
of this BSOD; it doesn't have to be a Windows update. For example, if
you're using a non-Microsoft AV program it might have quietly
downloaded a
buggy signature file, or even a program update. Ditto for device
drivers
written by some vendors.

And it's also possible that the latest change (Microsoft patch, AV
update,
whatever) triggered the failure, but wasn't where the broken code
can be
found. About 15 months ago I had a really nasty problem at my POE
where
users' systems died, in several cases, requiring reimaging. What
happened
was that buggy code had been loaded some time well before the failure,
but
its errors (probably wild stores into memory) didn't happen to hit
critical
data. When a Microsoft update to .NET changed memory layout, the
memory
location being corrupted became a critical field and the systems
died a
messy death. Making the diagnosis harder, different users had very
different symptoms.

Think of it as an IED planted (intentionally or not) in the logical
roadbed.

(This is one reason that we disable automatic updating in all
products we
support on user machines. Once we identified the Windows update as
the
trigger we pulled it from distribution and resumed its distribution
only
after removing the actual offender from all systems.)

Joe


I hear you.

I decided to restore the OS partition (C from an image done 3 days
ago
before all the problems started. I don't do automatic Windows
updates. I
ask Windows to download them and then notify me but I also tend to
install them very sson after the sytem tells me about it.

As I think back over the past day or two I now think the problems may
have stated after I used Revo Uninstall to uninstall something. Revo
goes much further than just a standard uninstall and I suspect it my
have done more than it should in its cleaning zeal. (May also later get
rid of Revo itself which I think has done something like this before)

Wish me luck.
Now this is ironic.

I decided to restore an image I had from 3 days ago. So I first made a
backup of the current situation and then restored the 3 day old one.
Guess what? The shutdown problem is still here. Will still not shut
down completely!
Because this is a new laptop I don't have earlier backups but have
installed a lot of software and therefore do not want to go back to
the factory state. Darn!

In the example here, the respondent was able to determine the critical
object
was "csrss". Which suggests, however that dump was read, it had a little
additional
information to give.

http://www.sevenforums.com/crashes-debugging/116679-bsod-critical_object_termination-error.html



http://en.wikipedia.org/wiki/Client/Server_Runtime_Subsystem

There's probably a couple of things that rate as critical, and I presume
the kernel is detecting this, in the interest of shutting down a
compromised system.

Sure, it could be a memory error (memory failure), but what are the
odds it
would hit just the right place ?

Other alternatives, would be to test with a Linux LiveCD (which
frequently includes
memtest as a boot time option), and you could test whether shutdown there
is "normal" or not. I'd only bother with that, if you had the Linux
LiveCD
already, rather than waste the time on a new download now.

Paul

I have several linux live CDs. Will try tomorrow.
Shame there is not a "repair" mode to W7.
I already checked the disk surface and it is fine and also ran a virus
heck with no problem. What a pain!

There's system file checker.

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

I don't know how much good that's going to do you.

*******

A repair install on Windows 7, I think it leaves a Windows.old kind of
folder. Which to me, isn't a repair. I presume what it does, is
load a fresh set of files, then copy over whatever it needs (like
the Registry files).

The article here, doesn't make the Repair Install a very appealing process.

http://www.sevenforums.com/tutorials/3413-repair-install.html

Now you know why I keep the odd backup of C: around, for my laptop...

Paul