WIA and hibernation again

William B. Lurie wrote:
William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:
William B. Lurie wrote:
(snip)

You can set all the services to Manual start if you want but I
don't know if it will change anything, give it a try and find
out. Keep these three services to Automatic start:

Event Log
Plug & Play
Remote Procedure Call (RPC)

Set all the other services to manual or disabled. After you do
this try to hibernate the machine manually or in less than one
hour (to make sure that it can actually hibernate with the
minimal set of services).

John
Okay, John, will do....later.
But for now, I'd like to report that my clone system is
running, with clean boot, such that it does hibernate
at 1 hour, giving no unexplainable event msgs or errors,
and no sign of the dreaded ati2mtag or whatever it is.

I followed above procedures, John, with eminent success (so far).
Stripping down to just those few, it hibernated at two hours!
Did it twice to make sure.
So I changed the first ten to automatic and again, it hibernated at
two hours. I did it twice to be sure.

That is progress...


So I changed the next 15 or so, and it did NOT go to 2 hours.

And there is the clue to your problem. Keep notes of your changes
and keep on narrowing things down. One of these 15 services
prevented hibernation, keep on whittling the list down, cut out 8
of the 15 services and see if things change. If it does hibernate
move on to the other 7 services, if it doesn't hibernate cut the 8
services list down to 4 and try it again... and so on until you
pinpoint it down to the culprit.


Here are
the Events. Critical timing is that it started at 7:43, should have
gone to 9:45, but things happened around 8:15, and desktop came on
and I discontinued, to capture Events Monitor and pass them along.
Perhaps you can interpret what they say, and tell me how to fix it,
maybe by disabling some culprit......or do I search one suspect at a
time until I find it? Got any clues? What is "Ci"?


Event Type: Information
Event Source: Ci
Event Category: CI Service Event ID: 4103
Date: 4/6/2010
Time: 8:16:59 AM
User: N/A
Computer: COMPAQ-2006
Description:
Master merge has completed on c:\system volume
information\catalog.wci.

That is caused by the Indexing Service. If you want you can read
about the Master Merge in these search results:

http://search.yahoo.com/search;_ylt=...r2=sfp&iscqry=


You can disable the Indexing Service and see if things change.



I can go back and narrow it down, but it would be nice to go back
to the
state where it ran 2 hours, and add just whatever you think is the
bad
actor.......

I don't know who the bad actor is, you will have to keep on with
the trial and error and find that bad actor! Remember what I said
earlier... "sometimes you need dogged determination to get to the
bottom of some of these problems".

John
Right, John, I agree heartily. It will take some time, but I will
go back to what was good (first batch of changes from base state)
and start adding. Index will be the first that I re-enable after
I get back to a good 2 hour run. The ball is in my court; I will
crawl along toward what I hope will be a solution.

Let us know what you find out!

John
Now 10 OM. I did as I said I would. Started with stripped, bare system.
Hibernation 2 hours okay.
I added Indexing *only*. It ran to 2 hours and hibernated perfectly.
No significant entries into events log.

In a way this was good news......and in another way, bad news.
Obvious next step. Keep Indexing Automatic along with your 3 basic
automatics, and start adding one at a time, the stuff that ended up,
in combination, causing the malfunction. Tedious......actually
tedious squared, or tedious factorial, I'm not sure which.

Your comments welcome, John, but the course seems pretty obvious.

Follow-on next morning. I stretched too far. In addition to 5 basic
plus Indexing, I added five more, and it blew again. And it isn't
trivial to diagnose why, from the Log. Back to adding just one at a
time. More later.
So the plot thickens. I went back to what worked, and re-activated just
one service, DCOM. It now refused to hibernate, and the event log
showed Service Control Manager error. I can go back and repeat the
steps if you feel it's not reasonable, John. But Now we are led from
DCOM (which is meaningless to me) to Service Control Manager, equally
meaningless, and I don't know if I need it in my running system, or if
I can safely leave it Manual (or Disabled) and go on with the next
service. Next step will be to make DCOM Manual again and wait for advice.

William B. Lurie wrote:
William B. Lurie wrote:
William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:
William B. Lurie wrote:
(snip)

You can set all the services to Manual start if you want but I
don't know if it will change anything, give it a try and find
out. Keep these three services to Automatic start:

Event Log
Plug & Play
Remote Procedure Call (RPC)

Set all the other services to manual or disabled. After you do
this try to hibernate the machine manually or in less than one
hour (to make sure that it can actually hibernate with the
minimal set of services).

John
Okay, John, will do....later.
But for now, I'd like to report that my clone system is
running, with clean boot, such that it does hibernate
at 1 hour, giving no unexplainable event msgs or errors,
and no sign of the dreaded ati2mtag or whatever it is.

I followed above procedures, John, with eminent success (so far).
Stripping down to just those few, it hibernated at two hours!
Did it twice to make sure.
So I changed the first ten to automatic and again, it hibernated at
two hours. I did it twice to be sure.

That is progress...


So I changed the next 15 or so, and it did NOT go to 2 hours.

And there is the clue to your problem. Keep notes of your changes
and keep on narrowing things down. One of these 15 services
prevented hibernation, keep on whittling the list down, cut out 8
of the 15 services and see if things change. If it does hibernate
move on to the other 7 services, if it doesn't hibernate cut the 8
services list down to 4 and try it again... and so on until you
pinpoint it down to the culprit.


Here are
the Events. Critical timing is that it started at 7:43, should have
gone to 9:45, but things happened around 8:15, and desktop came on
and I discontinued, to capture Events Monitor and pass them along.
Perhaps you can interpret what they say, and tell me how to fix it,
maybe by disabling some culprit......or do I search one suspect at a
time until I find it? Got any clues? What is "Ci"?


Event Type: Information
Event Source: Ci
Event Category: CI Service Event ID: 4103
Date: 4/6/2010
Time: 8:16:59 AM
User: N/A
Computer: COMPAQ-2006
Description:
Master merge has completed on c:\system volume
information\catalog.wci.

That is caused by the Indexing Service. If you want you can read
about the Master Merge in these search results:

http://search.yahoo.com/search;_ylt=...r2=sfp&iscqry=


You can disable the Indexing Service and see if things change.



I can go back and narrow it down, but it would be nice to go back
to the
state where it ran 2 hours, and add just whatever you think is
the bad
actor.......

I don't know who the bad actor is, you will have to keep on with
the trial and error and find that bad actor! Remember what I said
earlier... "sometimes you need dogged determination to get to the
bottom of some of these problems".

John
Right, John, I agree heartily. It will take some time, but I will
go back to what was good (first batch of changes from base state)
and start adding. Index will be the first that I re-enable after
I get back to a good 2 hour run. The ball is in my court; I will
crawl along toward what I hope will be a solution.

Let us know what you find out!

John
Now 10 OM. I did as I said I would. Started with stripped, bare system.
Hibernation 2 hours okay.
I added Indexing *only*. It ran to 2 hours and hibernated perfectly.
No significant entries into events log.

In a way this was good news......and in another way, bad news.
Obvious next step. Keep Indexing Automatic along with your 3 basic
automatics, and start adding one at a time, the stuff that ended up,
in combination, causing the malfunction. Tedious......actually
tedious squared, or tedious factorial, I'm not sure which.

Your comments welcome, John, but the course seems pretty obvious.

Follow-on next morning. I stretched too far. In addition to 5 basic
plus Indexing, I added five more, and it blew again. And it isn't
trivial to diagnose why, from the Log. Back to adding just one at a
time. More later.
So the plot thickens. I went back to what worked, and re-activated just
one service, DCOM. It now refused to hibernate, and the event log
showed Service Control Manager error. I can go back and repeat the
steps if you feel it's not reasonable, John. But Now we are led from
DCOM (which is meaningless to me) to Service Control Manager, equally
meaningless, and I don't know if I need it in my running system, or if
I can safely leave it Manual (or Disabled) and go on with the next
service. Next step will be to make DCOM Manual again and wait for advice.

I don't think that DCOM in itself is responsible, more likely it's
another application than is using DCOM that would be at fault. On a
production machine this service needs to be set to Automatic Start.
What errors are you seeing in the Event Log?

For your trouble shooting purposes you could leave DCOM to manual for
the time being and keep on with your other necessary services and see
what happens.

John

FYI--DCOM is set to automatic on my system and started. And I have no
problems with hibernate. I think
you are correct when you state something else interfacing/using DCOM is the
fault. My guess-----Norton simply
because of its notoriety. .
"John John - MVP" wrote in message
...
William B. Lurie wrote:
William B. Lurie wrote:
William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:
William B. Lurie wrote:
(snip)

You can set all the services to Manual start if you want but I
don't know if it will change anything, give it a try and find
out. Keep these three services to Automatic start:

Event Log
Plug & Play
Remote Procedure Call (RPC)

Set all the other services to manual or disabled. After you do
this try to hibernate the machine manually or in less than one
hour (to make sure that it can actually hibernate with the
minimal set of services).

John
Okay, John, will do....later.
But for now, I'd like to report that my clone system is
running, with clean boot, such that it does hibernate
at 1 hour, giving no unexplainable event msgs or errors,
and no sign of the dreaded ati2mtag or whatever it is.

I followed above procedures, John, with eminent success (so far).
Stripping down to just those few, it hibernated at two hours!
Did it twice to make sure.
So I changed the first ten to automatic and again, it hibernated at
two hours. I did it twice to be sure.

That is progress...


So I changed the next 15 or so, and it did NOT go to 2 hours.

And there is the clue to your problem. Keep notes of your changes
and keep on narrowing things down. One of these 15 services
prevented hibernation, keep on whittling the list down, cut out 8
of the 15 services and see if things change. If it does hibernate
move on to the other 7 services, if it doesn't hibernate cut the 8
services list down to 4 and try it again... and so on until you
pinpoint it down to the culprit.


Here are
the Events. Critical timing is that it started at 7:43, should have
gone to 9:45, but things happened around 8:15, and desktop came on
and I discontinued, to capture Events Monitor and pass them along.
Perhaps you can interpret what they say, and tell me how to fix it,
maybe by disabling some culprit......or do I search one suspect at
a
time until I find it? Got any clues? What is "Ci"?


Event Type: Information
Event Source: Ci
Event Category: CI Service Event ID: 4103
Date: 4/6/2010
Time: 8:16:59 AM
User: N/A
Computer: COMPAQ-2006
Description:
Master merge has completed on c:\system volume
information\catalog.wci.

That is caused by the Indexing Service. If you want you can read
about the Master Merge in these search results:

http://search.yahoo.com/search;_ylt=...r2=sfp&iscqry=

You can disable the Indexing Service and see if things change.



I can go back and narrow it down, but it would be nice to go back
to the
state where it ran 2 hours, and add just whatever you think is the
bad
actor.......

I don't know who the bad actor is, you will have to keep on with the
trial and error and find that bad actor! Remember what I said
earlier... "sometimes you need dogged determination to get to the
bottom of some of these problems".

John
Right, John, I agree heartily. It will take some time, but I will
go back to what was good (first batch of changes from base state)
and start adding. Index will be the first that I re-enable after
I get back to a good 2 hour run. The ball is in my court; I will
crawl along toward what I hope will be a solution.

Let us know what you find out!

John
Now 10 OM. I did as I said I would. Started with stripped, bare system.
Hibernation 2 hours okay.
I added Indexing *only*. It ran to 2 hours and hibernated perfectly.
No significant entries into events log.

In a way this was good news......and in another way, bad news.
Obvious next step. Keep Indexing Automatic along with your 3 basic
automatics, and start adding one at a time, the stuff that ended up,
in combination, causing the malfunction. Tedious......actually
tedious squared, or tedious factorial, I'm not sure which.

Your comments welcome, John, but the course seems pretty obvious.

Follow-on next morning. I stretched too far. In addition to 5 basic
plus Indexing, I added five more, and it blew again. And it isn't
trivial to diagnose why, from the Log. Back to adding just one at a
time. More later.
So the plot thickens. I went back to what worked, and re-activated just
one service, DCOM. It now refused to hibernate, and the event log
showed Service Control Manager error. I can go back and repeat the
steps if you feel it's not reasonable, John. But Now we are led from DCOM
(which is meaningless to me) to Service Control Manager, equally
meaningless, and I don't know if I need it in my running system, or if
I can safely leave it Manual (or Disabled) and go on with the next
service. Next step will be to make DCOM Manual again and wait for advice.

I don't think that DCOM in itself is responsible, more likely it's another
application than is using DCOM that would be at fault. On a production
machine this service needs to be set to Automatic Start. What errors are
you seeing in the Event Log?

For your trouble shooting purposes you could leave DCOM to manual for the
time being and keep on with your other necessary services and see what
happens.

John

My guess too, (Norton), and I've had it as a suspect from the very
beginning.

John

Unknown wrote:
FYI--DCOM is set to automatic on my system and started. And I have no
problems with hibernate. I think
you are correct when you state something else interfacing/using DCOM is the
fault. My guess-----Norton simply
because of its notoriety. .
"John John - MVP" wrote in message
...
William B. Lurie wrote:
William B. Lurie wrote:
William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:
William B. Lurie wrote:
(snip)
You can set all the services to Manual start if you want but I
don't know if it will change anything, give it a try and find
out. Keep these three services to Automatic start:

Event Log
Plug & Play
Remote Procedure Call (RPC)

Set all the other services to manual or disabled. After you do
this try to hibernate the machine manually or in less than one
hour (to make sure that it can actually hibernate with the
minimal set of services).

John
Okay, John, will do....later.
But for now, I'd like to report that my clone system is
running, with clean boot, such that it does hibernate
at 1 hour, giving no unexplainable event msgs or errors,
and no sign of the dreaded ati2mtag or whatever it is.
I followed above procedures, John, with eminent success (so far).
Stripping down to just those few, it hibernated at two hours!
Did it twice to make sure.
So I changed the first ten to automatic and again, it hibernated at
two hours. I did it twice to be sure.
That is progress...


So I changed the next 15 or so, and it did NOT go to 2 hours.
And there is the clue to your problem. Keep notes of your changes
and keep on narrowing things down. One of these 15 services
prevented hibernation, keep on whittling the list down, cut out 8
of the 15 services and see if things change. If it does hibernate
move on to the other 7 services, if it doesn't hibernate cut the 8
services list down to 4 and try it again... and so on until you
pinpoint it down to the culprit.


Here are
the Events. Critical timing is that it started at 7:43, should have
gone to 9:45, but things happened around 8:15, and desktop came on
and I discontinued, to capture Events Monitor and pass them along.
Perhaps you can interpret what they say, and tell me how to fix it,
maybe by disabling some culprit......or do I search one suspect at
a
time until I find it? Got any clues? What is "Ci"?

Event Type: Information
Event Source: Ci
Event Category: CI Service Event ID: 4103
Date: 4/6/2010
Time: 8:16:59 AM
User: N/A
Computer: COMPAQ-2006
Description:
Master merge has completed on c:\system volume
information\catalog.wci.
That is caused by the Indexing Service. If you want you can read
about the Master Merge in these search results:

http://search.yahoo.com/search;_ylt=...r2=sfp&iscqry=

You can disable the Indexing Service and see if things change.



I can go back and narrow it down, but it would be nice to go back
to the
state where it ran 2 hours, and add just whatever you think is the
bad
actor.......
I don't know who the bad actor is, you will have to keep on with the
trial and error and find that bad actor! Remember what I said
earlier... "sometimes you need dogged determination to get to the
bottom of some of these problems".

John
Right, John, I agree heartily. It will take some time, but I will
go back to what was good (first batch of changes from base state)
and start adding. Index will be the first that I re-enable after
I get back to a good 2 hour run. The ball is in my court; I will
crawl along toward what I hope will be a solution.
Let us know what you find out!

John
Now 10 OM. I did as I said I would. Started with stripped, bare system.
Hibernation 2 hours okay.
I added Indexing *only*. It ran to 2 hours and hibernated perfectly.
No significant entries into events log.

In a way this was good news......and in another way, bad news.
Obvious next step. Keep Indexing Automatic along with your 3 basic
automatics, and start adding one at a time, the stuff that ended up,
in combination, causing the malfunction. Tedious......actually
tedious squared, or tedious factorial, I'm not sure which.

Your comments welcome, John, but the course seems pretty obvious.
Follow-on next morning. I stretched too far. In addition to 5 basic
plus Indexing, I added five more, and it blew again. And it isn't
trivial to diagnose why, from the Log. Back to adding just one at a
time. More later.
So the plot thickens. I went back to what worked, and re-activated just
one service, DCOM. It now refused to hibernate, and the event log
showed Service Control Manager error. I can go back and repeat the
steps if you feel it's not reasonable, John. But Now we are led from DCOM
(which is meaningless to me) to Service Control Manager, equally
meaningless, and I don't know if I need it in my running system, or if
I can safely leave it Manual (or Disabled) and go on with the next
service. Next step will be to make DCOM Manual again and wait for advice.
I don't think that DCOM in itself is responsible, more likely it's another
application than is using DCOM that would be at fault. On a production
machine this service needs to be set to Automatic Start. What errors are
you seeing in the Event Log?

For your trouble shooting purposes you could leave DCOM to manual for the
time being and keep on with your other necessary services and see what
happens.

John

UNk and JJ:
Excuse me, but have I not been testing with all Norton
software not even loaded? Much less in service....
Everybody always suspects Norton, but how can they be
guilty in this case? What can I do to guarantee that
they are completely out of the picture?

Am I missing something here? My ground rules are
Clean Boot every time, load no more than it takes to make
the system run so that I can add services (and eventually
applications) and have a system that turns itself off as
it should after 2 hours of being idle.

Okay, John, I'm back to where the first batch of services
is on automatic, DCOM is manual and hibernate is okay. I'll
leave DCOM on manual, and see what running the next listed
service on automatic tells us.

John John - MVP wrote:
My guess too, (Norton), and I've had it as a suspect from the very
beginning.

John

Unknown wrote:
FYI--DCOM is set to automatic on my system and started. And I have no
problems with hibernate. I think
you are correct when you state something else interfacing/using DCOM
is the fault. My guess-----Norton simply
because of its notoriety. .
"John John - MVP" wrote in message
...
William B. Lurie wrote:
William B. Lurie wrote:
William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:
William B. Lurie wrote:
(snip)
You can set all the services to Manual start if you want but
I don't know if it will change anything, give it a try and
find out. Keep these three services to Automatic start:

Event Log
Plug & Play
Remote Procedure Call (RPC)

Set all the other services to manual or disabled. After you
do this try to hibernate the machine manually or in less
than one hour (to make sure that it can actually hibernate
with the minimal set of services).

John
Okay, John, will do....later.
But for now, I'd like to report that my clone system is
running, with clean boot, such that it does hibernate
at 1 hour, giving no unexplainable event msgs or errors,
and no sign of the dreaded ati2mtag or whatever it is.
I followed above procedures, John, with eminent success (so far).
Stripping down to just those few, it hibernated at two hours!
Did it twice to make sure.
So I changed the first ten to automatic and again, it
hibernated at
two hours. I did it twice to be sure.
That is progress...


So I changed the next 15 or so, and it did NOT go to 2 hours.
And there is the clue to your problem. Keep notes of your
changes and keep on narrowing things down. One of these 15
services prevented hibernation, keep on whittling the list
down, cut out 8 of the 15 services and see if things change.
If it does hibernate move on to the other 7 services, if it
doesn't hibernate cut the 8 services list down to 4 and try it
again... and so on until you pinpoint it down to the culprit.


Here are
the Events. Critical timing is that it started at 7:43, should
have
gone to 9:45, but things happened around 8:15, and desktop
came on
and I discontinued, to capture Events Monitor and pass them
along.
Perhaps you can interpret what they say, and tell me how to
fix it,
maybe by disabling some culprit......or do I search one
suspect at a
time until I find it? Got any clues? What is "Ci"?

Event Type: Information
Event Source: Ci
Event Category: CI Service Event ID: 4103
Date: 4/6/2010
Time: 8:16:59 AM
User: N/A
Computer: COMPAQ-2006
Description:
Master merge has completed on c:\system volume
information\catalog.wci.
That is caused by the Indexing Service. If you want you can
read about the Master Merge in these search results:

http://search.yahoo.com/search;_ylt=...r2=sfp&iscqry=


You can disable the Indexing Service and see if things change.



I can go back and narrow it down, but it would be nice to go
back to the
state where it ran 2 hours, and add just whatever you think is
the bad
actor.......
I don't know who the bad actor is, you will have to keep on
with the trial and error and find that bad actor! Remember
what I said earlier... "sometimes you need dogged determination
to get to the bottom of some of these problems".

John
Right, John, I agree heartily. It will take some time, but I will
go back to what was good (first batch of changes from base state)
and start adding. Index will be the first that I re-enable after
I get back to a good 2 hour run. The ball is in my court; I will
crawl along toward what I hope will be a solution.
Let us know what you find out!

John
Now 10 OM. I did as I said I would. Started with stripped, bare
system.
Hibernation 2 hours okay.
I added Indexing *only*. It ran to 2 hours and hibernated perfectly.
No significant entries into events log.

In a way this was good news......and in another way, bad news.
Obvious next step. Keep Indexing Automatic along with your 3 basic
automatics, and start adding one at a time, the stuff that ended up,
in combination, causing the malfunction. Tedious......actually
tedious squared, or tedious factorial, I'm not sure which.

Your comments welcome, John, but the course seems pretty obvious.
Follow-on next morning. I stretched too far. In addition to 5 basic
plus Indexing, I added five more, and it blew again. And it isn't
trivial to diagnose why, from the Log. Back to adding just one at a
time. More later.
So the plot thickens. I went back to what worked, and re-activated
just one service, DCOM. It now refused to hibernate, and the event log
showed Service Control Manager error. I can go back and repeat the
steps if you feel it's not reasonable, John. But Now we are led from
DCOM (which is meaningless to me) to Service Control Manager, equally
meaningless, and I don't know if I need it in my running system, or if
I can safely leave it Manual (or Disabled) and go on with the next
service. Next step will be to make DCOM Manual again and wait for
advice.
I don't think that DCOM in itself is responsible, more likely it's
another application than is using DCOM that would be at fault. On a
production machine this service needs to be set to Automatic Start.
What errors are you seeing in the Event Log?

For your trouble shooting purposes you could leave DCOM to manual for
the time being and keep on with your other necessary services and see
what happens.

John

William B. Lurie wrote:
UNk and JJ:
Excuse me, but have I not been testing with all Norton
software not even loaded? Much less in service....
Everybody always suspects Norton, but how can they be
guilty in this case? What can I do to guarantee that
they are completely out of the picture?

Am I missing something here? My ground rules are
Clean Boot every time, load no more than it takes to make
the system run so that I can add services (and eventually
applications) and have a system that turns itself off as
it should after 2 hours of being idle.

Okay, John, I'm back to where the first batch of services
is on automatic, DCOM is manual and hibernate is okay. I'll
leave DCOM on manual, and see what running the next listed
service on automatic tells us.

John John - MVP wrote:
My guess too, (Norton), and I've had it as a suspect from the very
beginning.

John

Unknown wrote:
FYI--DCOM is set to automatic on my system and started. And I have no
problems with hibernate. I think
you are correct when you state something else interfacing/using DCOM
is the fault. My guess-----Norton simply
because of its notoriety. .
"John John - MVP" wrote in message
...
William B. Lurie wrote:
William B. Lurie wrote:
William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:
William B. Lurie wrote:
(snip)
You can set all the services to Manual start if you want
but I don't know if it will change anything, give it a try
and find out. Keep these three services to Automatic start:

Event Log
Plug & Play
Remote Procedure Call (RPC)

Set all the other services to manual or disabled. After
you do this try to hibernate the machine manually or in
less than one hour (to make sure that it can actually
hibernate with the minimal set of services).

John
Okay, John, will do....later.
But for now, I'd like to report that my clone system is
running, with clean boot, such that it does hibernate
at 1 hour, giving no unexplainable event msgs or errors,
and no sign of the dreaded ati2mtag or whatever it is.
I followed above procedures, John, with eminent success (so
far).
Stripping down to just those few, it hibernated at two hours!
Did it twice to make sure.
So I changed the first ten to automatic and again, it
hibernated at
two hours. I did it twice to be sure.
That is progress...


So I changed the next 15 or so, and it did NOT go to 2 hours.
And there is the clue to your problem. Keep notes of your
changes and keep on narrowing things down. One of these 15
services prevented hibernation, keep on whittling the list
down, cut out 8 of the 15 services and see if things change.
If it does hibernate move on to the other 7 services, if it
doesn't hibernate cut the 8 services list down to 4 and try it
again... and so on until you pinpoint it down to the culprit.


Here are
the Events. Critical timing is that it started at 7:43,
should have
gone to 9:45, but things happened around 8:15, and desktop
came on
and I discontinued, to capture Events Monitor and pass them
along.
Perhaps you can interpret what they say, and tell me how to
fix it,
maybe by disabling some culprit......or do I search one
suspect at a
time until I find it? Got any clues? What is "Ci"?

Event Type: Information
Event Source: Ci
Event Category: CI Service Event ID: 4103
Date: 4/6/2010
Time: 8:16:59 AM
User: N/A
Computer: COMPAQ-2006
Description:
Master merge has completed on c:\system volume
information\catalog.wci.
That is caused by the Indexing Service. If you want you can
read about the Master Merge in these search results:

http://search.yahoo.com/search;_ylt=...r2=sfp&iscqry=


You can disable the Indexing Service and see if things change.



I can go back and narrow it down, but it would be nice to go
back to the
state where it ran 2 hours, and add just whatever you think
is the bad
actor.......
I don't know who the bad actor is, you will have to keep on
with the trial and error and find that bad actor! Remember
what I said earlier... "sometimes you need dogged
determination to get to the bottom of some of these problems".

John
Right, John, I agree heartily. It will take some time, but I will
go back to what was good (first batch of changes from base state)
and start adding. Index will be the first that I re-enable after
I get back to a good 2 hour run. The ball is in my court; I will
crawl along toward what I hope will be a solution.
Let us know what you find out!

John
Now 10 OM. I did as I said I would. Started with stripped, bare
system.
Hibernation 2 hours okay.
I added Indexing *only*. It ran to 2 hours and hibernated perfectly.
No significant entries into events log.

In a way this was good news......and in another way, bad news.
Obvious next step. Keep Indexing Automatic along with your 3 basic
automatics, and start adding one at a time, the stuff that ended up,
in combination, causing the malfunction. Tedious......actually
tedious squared, or tedious factorial, I'm not sure which.

Your comments welcome, John, but the course seems pretty obvious.
Follow-on next morning. I stretched too far. In addition to 5 basic
plus Indexing, I added five more, and it blew again. And it isn't
trivial to diagnose why, from the Log. Back to adding just one at
a time. More later.
So the plot thickens. I went back to what worked, and re-activated
just one service, DCOM. It now refused to hibernate, and the event log
showed Service Control Manager error. I can go back and repeat the
steps if you feel it's not reasonable, John. But Now we are led
from DCOM (which is meaningless to me) to Service Control Manager,
equally
meaningless, and I don't know if I need it in my running system, or if
I can safely leave it Manual (or Disabled) and go on with the next
service. Next step will be to make DCOM Manual again and wait for
advice.
I don't think that DCOM in itself is responsible, more likely it's
another application than is using DCOM that would be at fault. On a
production machine this service needs to be set to Automatic Start.
What errors are you seeing in the Event Log?

For your trouble shooting purposes you could leave DCOM to manual
for the time being and keep on with your other necessary services
and see what happens.

John


John, the next test was inconclusive because I may not have
waited quite 2 hours, but it is already beginning to look as
though the length of time to test with DCOM plus each succeeding
service, and then the next one plus each of the rest, will end
some time in the next decade, not this one. I'll pursue this tack
a bit further, but it seems to me that *somebody*, maybe another
one of the excellent MVPs, might know which 'service' has a one
hour time clock built into it.

William B. Lurie wrote:
William B. Lurie wrote:
UNk and JJ:
Excuse me, but have I not been testing with all Norton
software not even loaded? Much less in service....
Everybody always suspects Norton, but how can they be
guilty in this case? What can I do to guarantee that
they are completely out of the picture?

Am I missing something here? My ground rules are
Clean Boot every time, load no more than it takes to make
the system run so that I can add services (and eventually
applications) and have a system that turns itself off as
it should after 2 hours of being idle.

Okay, John, I'm back to where the first batch of services
is on automatic, DCOM is manual and hibernate is okay. I'll
leave DCOM on manual, and see what running the next listed
service on automatic tells us.

John John - MVP wrote:
My guess too, (Norton), and I've had it as a suspect from the very
beginning.

John

Unknown wrote:
FYI--DCOM is set to automatic on my system and started. And I have
no problems with hibernate. I think
you are correct when you state something else interfacing/using DCOM
is the fault. My guess-----Norton simply
because of its notoriety. .
"John John - MVP" wrote in message
...
William B. Lurie wrote:
William B. Lurie wrote:
William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:
William B. Lurie wrote:
(snip)
You can set all the services to Manual start if you want
but I don't know if it will change anything, give it a try
and find out. Keep these three services to Automatic start:

Event Log
Plug & Play
Remote Procedure Call (RPC)

Set all the other services to manual or disabled. After
you do this try to hibernate the machine manually or in
less than one hour (to make sure that it can actually
hibernate with the minimal set of services).

John
Okay, John, will do....later.
But for now, I'd like to report that my clone system is
running, with clean boot, such that it does hibernate
at 1 hour, giving no unexplainable event msgs or errors,
and no sign of the dreaded ati2mtag or whatever it is.
I followed above procedures, John, with eminent success (so
far).
Stripping down to just those few, it hibernated at two hours!
Did it twice to make sure.
So I changed the first ten to automatic and again, it
hibernated at
two hours. I did it twice to be sure.
That is progress...


So I changed the next 15 or so, and it did NOT go to 2 hours.
And there is the clue to your problem. Keep notes of your
changes and keep on narrowing things down. One of these 15
services prevented hibernation, keep on whittling the list
down, cut out 8 of the 15 services and see if things change.
If it does hibernate move on to the other 7 services, if it
doesn't hibernate cut the 8 services list down to 4 and try
it again... and so on until you pinpoint it down to the culprit.


Here are
the Events. Critical timing is that it started at 7:43,
should have
gone to 9:45, but things happened around 8:15, and desktop
came on
and I discontinued, to capture Events Monitor and pass them
along.
Perhaps you can interpret what they say, and tell me how to
fix it,
maybe by disabling some culprit......or do I search one
suspect at a
time until I find it? Got any clues? What is "Ci"?

Event Type: Information
Event Source: Ci
Event Category: CI Service Event ID: 4103
Date: 4/6/2010
Time: 8:16:59 AM
User: N/A
Computer: COMPAQ-2006
Description:
Master merge has completed on c:\system volume
information\catalog.wci.
That is caused by the Indexing Service. If you want you can
read about the Master Merge in these search results:

http://search.yahoo.com/search;_ylt=...r2=sfp&iscqry=


You can disable the Indexing Service and see if things change.



I can go back and narrow it down, but it would be nice to go
back to the
state where it ran 2 hours, and add just whatever you think
is the bad
actor.......
I don't know who the bad actor is, you will have to keep on
with the trial and error and find that bad actor! Remember
what I said earlier... "sometimes you need dogged
determination to get to the bottom of some of these problems".

John
Right, John, I agree heartily. It will take some time, but I will
go back to what was good (first batch of changes from base state)
and start adding. Index will be the first that I re-enable after
I get back to a good 2 hour run. The ball is in my court; I will
crawl along toward what I hope will be a solution.
Let us know what you find out!

John
Now 10 OM. I did as I said I would. Started with stripped, bare
system.
Hibernation 2 hours okay.
I added Indexing *only*. It ran to 2 hours and hibernated
perfectly.
No significant entries into events log.

In a way this was good news......and in another way, bad news.
Obvious next step. Keep Indexing Automatic along with your 3 basic
automatics, and start adding one at a time, the stuff that ended
up,
in combination, causing the malfunction. Tedious......actually
tedious squared, or tedious factorial, I'm not sure which.

Your comments welcome, John, but the course seems pretty obvious.
Follow-on next morning. I stretched too far. In addition to 5 basic
plus Indexing, I added five more, and it blew again. And it isn't
trivial to diagnose why, from the Log. Back to adding just one at
a time. More later.
So the plot thickens. I went back to what worked, and re-activated
just one service, DCOM. It now refused to hibernate, and the event
log
showed Service Control Manager error. I can go back and repeat the
steps if you feel it's not reasonable, John. But Now we are led
from DCOM (which is meaningless to me) to Service Control Manager,
equally
meaningless, and I don't know if I need it in my running system,
or if
I can safely leave it Manual (or Disabled) and go on with the next
service. Next step will be to make DCOM Manual again and wait for
advice.
I don't think that DCOM in itself is responsible, more likely it's
another application than is using DCOM that would be at fault. On
a production machine this service needs to be set to Automatic
Start. What errors are you seeing in the Event Log?

For your trouble shooting purposes you could leave DCOM to manual
for the time being and keep on with your other necessary services
and see what happens.

John


John, the next test was inconclusive because I may not have
waited quite 2 hours, but it is already beginning to look as
though the length of time to test with DCOM plus each succeeding
service, and then the next one plus each of the rest, will end
some time in the next decade, not this one. I'll pursue this tack
a bit further, but it seems to me that *somebody*, maybe another
one of the excellent MVPs, might know which 'service' has a one
hour time clock built into it.

I would enable them in batches of 10 or more services, not one at a
time, this should speed things up a bit. Also, I *always* keep these
services disabled on almost any machine that I ever work with:

Alerter
Clipbook
Human Interface Device Access
Net.Tcp Port Sharing Service
Network DDE
Network DDE DSDM
Remote Registry
SSDP Discovery Service
Telnet
Universal Plug and Play Device Host

I suggest you set them to disabled and forget about them, so that's a
batch of 10 services out of the way!

You can also use Process Monitor and see what it captures, it will show
you which processes were running and at what time they ran.

http://technet.microsoft.com/en-us/s.../bb896645.aspx

John

John, the next test was inconclusive because I may not have
waited quite 2 hours, but it is already beginning to look as
though the length of time to test with DCOM plus each succeeding
service, and then the next one plus each of the rest, will end
some time in the next decade, not this one. I'll pursue this tack
a bit further, but it seems to me that *somebody*, maybe another
one of the excellent MVPs, might know which 'service' has a one
hour time clock built into it.

I've snipped everything out because I think we're at a decision-
making point. I just don't think that the try-each-service approach
is going to be practical. Just too many services, too many possible
combinations, too little known about each, too long to make just one
test. I agree it's logical and sensible and proper scientific
technique, but it's like counting the grains of sand on the beach.

Getting back to the 1 hour/2 hour problem, I feel we have eliminated
any running application program as a source, by just not loading them.
If they don't load, they don't execute, and if they don't execute,
they can't influence hibernation.

So what *is* running? The system and its big-brother-given 'services'.
Rereading my last comment above, I hope I didn't offend anybody, but we
have to realize how enormously complex the XP system is, and it's too
much to expect any MVP to be intimately familiar with the inner workings
of all of its services. That's approaching the problem from the bottom
up. The question, down from the top, is, can we pick enough MVPs' brains
hard enough to find out which of the services is capable of preventing
the supposedly idle system from hibernating after 2 hours, but not after
only 1 hour.

William B. Lurie wrote:



John, the next test was inconclusive because I may not have
waited quite 2 hours, but it is already beginning to look as
though the length of time to test with DCOM plus each succeeding
service, and then the next one plus each of the rest, will end
some time in the next decade, not this one. I'll pursue this tack
a bit further, but it seems to me that *somebody*, maybe another
one of the excellent MVPs, might know which 'service' has a one
hour time clock built into it.

I've snipped everything out because I think we're at a decision-
making point. I just don't think that the try-each-service approach
is going to be practical.

No, it isn't, that is why it's best to do it in batches of 10 services
or so...


[snip...}

So what *is* running?

Sysinternals' Process Monitor will tell you that...

John

How does your NORTON program get updated? Is it automatic?
"William B. Lurie" wrote in message
...



John, the next test was inconclusive because I may not have
waited quite 2 hours, but it is already beginning to look as
though the length of time to test with DCOM plus each succeeding service,
and then the next one plus each of the rest, will end
some time in the next decade, not this one. I'll pursue this tack
a bit further, but it seems to me that *somebody*, maybe another
one of the excellent MVPs, might know which 'service' has a one
hour time clock built into it.

I've snipped everything out because I think we're at a decision-
making point. I just don't think that the try-each-service approach
is going to be practical. Just too many services, too many possible
combinations, too little known about each, too long to make just one
test. I agree it's logical and sensible and proper scientific
technique, but it's like counting the grains of sand on the beach.

Getting back to the 1 hour/2 hour problem, I feel we have eliminated
any running application program as a source, by just not loading them.
If they don't load, they don't execute, and if they don't execute,
they can't influence hibernation.

So what *is* running? The system and its big-brother-given 'services'.
Rereading my last comment above, I hope I didn't offend anybody, but we
have to realize how enormously complex the XP system is, and it's too
much to expect any MVP to be intimately familiar with the inner workings
of all of its services. That's approaching the problem from the bottom
up. The question, down from the top, is, can we pick enough MVPs' brains
hard enough to find out which of the services is capable of preventing
the supposedly idle system from hibernating after 2 hours, but not after
only 1 hour.

Unknown wrote:
How does your NORTON program get updated? Is it automatic?

No, I *never* allow any software supplier to do automatic
stuff. Norton has automatic live update, which I keep
turned off. I do manual live update periodically. That goes especially
for Windows as well.

John, I'd be willing to look at that what's-running-monitor,
how do I grab it?

"William B. Lurie" wrote in message
...

John, the next test was inconclusive because I may not have
waited quite 2 hours, but it is already beginning to look as
though the length of time to test with DCOM plus each succeeding service,
and then the next one plus each of the rest, will end
some time in the next decade, not this one. I'll pursue this tack
a bit further, but it seems to me that *somebody*, maybe another
one of the excellent MVPs, might know which 'service' has a one
hour time clock built into it.
I've snipped everything out because I think we're at a decision-
making point. I just don't think that the try-each-service approach
is going to be practical. Just too many services, too many possible
combinations, too little known about each, too long to make just one
test. I agree it's logical and sensible and proper scientific
technique, but it's like counting the grains of sand on the beach.

Getting back to the 1 hour/2 hour problem, I feel we have eliminated
any running application program as a source, by just not loading them.
If they don't load, they don't execute, and if they don't execute,
they can't influence hibernation.

So what *is* running? The system and its big-brother-given 'services'.
Rereading my last comment above, I hope I didn't offend anybody, but we
have to realize how enormously complex the XP system is, and it's too
much to expect any MVP to be intimately familiar with the inner workings
of all of its services. That's approaching the problem from the bottom
up. The question, down from the top, is, can we pick enough MVPs' brains
hard enough to find out which of the services is capable of preventing
the supposedly idle system from hibernating after 2 hours, but not after
only 1 hour.

John John - MVP wrote:
William B. Lurie wrote:



John, the next test was inconclusive because I may not have
waited quite 2 hours, but it is already beginning to look as
though the length of time to test with DCOM plus each succeeding
service, and then the next one plus each of the rest, will end
some time in the next decade, not this one. I'll pursue this tack
a bit further, but it seems to me that *somebody*, maybe another
one of the excellent MVPs, might know which 'service' has a one
hour time clock built into it.

I've snipped everything out because I think we're at a decision-
making point. I just don't think that the try-each-service approach
is going to be practical.

No, it isn't, that is why it's best to do it in batches of 10 services
or so...

I'd love to be able to do 10 at a shot, especially since there
are over 100 to do, John. But In 2 tries, at doing only one at
a time, one was acceptable and the second single blew. I have
no reason to expect that 10 would play... (remember, my first bank of
10 was successful, the next one failed). How do I see Sysinternals'

Process Monitor?

[snip...}

So what *is* running?

Sysinternals' Process Monitor will tell you that...

John

William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:



John, the next test was inconclusive because I may not have
waited quite 2 hours, but it is already beginning to look as
though the length of time to test with DCOM plus each succeeding
service, and then the next one plus each of the rest, will end
some time in the next decade, not this one. I'll pursue this tack
a bit further, but it seems to me that *somebody*, maybe another
one of the excellent MVPs, might know which 'service' has a one
hour time clock built into it.

I've snipped everything out because I think we're at a decision-
making point. I just don't think that the try-each-service approach
is going to be practical.

No, it isn't, that is why it's best to do it in batches of 10 services
or so...

I'd love to be able to do 10 at a shot, especially since there
are over 100 to do, John. But In 2 tries, at doing only one at
a time, one was acceptable and the second single blew. I have
no reason to expect that 10 would play... (remember, my first bank of
10 was successful, the next one failed).

You don't need to put all the services on Automatic start! Just do the
necessary ones, leave all the others to Manual.

I already gave you a list of 10 services which you should keep Disabled.
I don't know what you run on your computer but of the remaining list
set these to Automatic and see what happens:

Cryptographic Services
DCOM Server Process Launcher
DHCP Client
Event Log
Plug and Play
Print Spooler
Protected Storage
Remote Procedure Call (RPC)
Security Accounts Manager
Shell Hardware Detection
System Event Notification
System Restore Service
Task Scheduler
Themes **
Windows Audio
Windows Management Instrumentation
Workstation

** If you are using Themes, if you use Classic look only you don't need
this on Automatic.

Of course, depending on what you do with your computer, you're probably
going to need to have a few other services set to start automatically
but the above list is all that is needed for most users who run
standalone machines.


How do I see Sysinternals' Process Monitor?

http://technet.microsoft.com/en-us/s.../bb896645.aspx

John

John John - MVP wrote:
William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:



John, the next test was inconclusive because I may not have
waited quite 2 hours, but it is already beginning to look as
though the length of time to test with DCOM plus each succeeding
service, and then the next one plus each of the rest, will end
some time in the next decade, not this one. I'll pursue this tack
a bit further, but it seems to me that *somebody*, maybe another
one of the excellent MVPs, might know which 'service' has a one
hour time clock built into it.

I've snipped everything out because I think we're at a decision-
making point. I just don't think that the try-each-service approach
is going to be practical.

No, it isn't, that is why it's best to do it in batches of 10
services or so...

I'd love to be able to do 10 at a shot, especially since there
are over 100 to do, John. But In 2 tries, at doing only one at
a time, one was acceptable and the second single blew. I have
no reason to expect that 10 would play... (remember, my first bank of
10 was successful, the next one failed).

You don't need to put all the services on Automatic start! Just do the
necessary ones, leave all the others to Manual.

I already gave you a list of 10 services which you should keep Disabled.
I don't know what you run on your computer but of the remaining list
set these to Automatic and see what happens:

Cryptographic Services
DCOM Server Process Launcher
DHCP Client
Event Log
Plug and Play
Print Spooler
Protected Storage
Remote Procedure Call (RPC)
Security Accounts Manager
Shell Hardware Detection
System Event Notification
System Restore Service
Task Scheduler
Themes **
Windows Audio
Windows Management Instrumentation
Workstation

** If you are using Themes, if you use Classic look only you don't need
this on Automatic.

Of course, depending on what you do with your computer, you're probably
going to need to have a few other services set to start automatically
but the above list is all that is needed for most users who run
standalone machines.


How do I see Sysinternals' Process Monitor?

http://technet.microsoft.com/en-us/s.../bb896645.aspx

John
Okay, John, I'll set those to Automatic. But that still leaves about
70 more. BTW, what about RPC (Locator)? And do I really want to
make Event Log Automatic?

William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:
John John - MVP wrote:
William B. Lurie wrote:



John, the next test was inconclusive because I may not have
waited quite 2 hours, but it is already beginning to look as
though the length of time to test with DCOM plus each succeeding
service, and then the next one plus each of the rest, will end
some time in the next decade, not this one. I'll pursue this tack
a bit further, but it seems to me that *somebody*, maybe another
one of the excellent MVPs, might know which 'service' has a one
hour time clock built into it.

I've snipped everything out because I think we're at a decision-
making point. I just don't think that the try-each-service approach
is going to be practical.

No, it isn't, that is why it's best to do it in batches of 10
services or so...

I'd love to be able to do 10 at a shot, especially since there
are over 100 to do, John. But In 2 tries, at doing only one at
a time, one was acceptable and the second single blew. I have
no reason to expect that 10 would play... (remember, my first bank of
10 was successful, the next one failed).

You don't need to put all the services on Automatic start! Just do
the necessary ones, leave all the others to Manual.

I already gave you a list of 10 services which you should keep
Disabled. I don't know what you run on your computer but of the
remaining list set these to Automatic and see what happens:

Cryptographic Services
DCOM Server Process Launcher
DHCP Client
Event Log
Plug and Play
Print Spooler
Protected Storage
Remote Procedure Call (RPC)
Security Accounts Manager
Shell Hardware Detection
System Event Notification
System Restore Service
Task Scheduler
Themes **
Windows Audio
Windows Management Instrumentation
Workstation

** If you are using Themes, if you use Classic look only you don't
need this on Automatic.

Of course, depending on what you do with your computer, you're
probably going to need to have a few other services set to start
automatically but the above list is all that is needed for most users
who run standalone machines.


How do I see Sysinternals' Process Monitor?

http://technet.microsoft.com/en-us/s.../bb896645.aspx

John
Okay, John, I'll set those to Automatic. But that still leaves about
70 more.

Don't worry about those 70 other ones, at least not for now. Most of
them can stay on Manual, the operating system will start them if they
are needed. Being on manual doesn't mean that they can't be run, it
just means that they won't start unless they are needed. There are a
few others that you will probably want to have on Automatic but you can
deal with those in the "second" batch of trial services, for the time
being stick with the above.


BTW, what about RPC (Locator)?

Leave it on manual, that is the default setting for it when you install
Windows, there is no need to have it set to Automatic.


And do I really want to make Event Log Automatic?

Yes, ABSOLUTELY! Always!

John