Dr. Watson & Win98SE

Would someone please verify the following understanding I
have about Dr. Watson use within Win98SE, and suggest a way
to troubleshoot the problem described:

1) Dr. Watson CAN collect stack/frame (minidumps) of a
program fault.
A program fault, as I understand the use of Dr. Watson, is
where an application program causes a (minidump) to be
captured, and the system stays up and the Dr. Watson log of
the event can be collected. From what I have read at the
Microsoft site, this is what happens when Dr. Watson is
able to collect a log of a program fault event.

2) Dr. Watson CANNOT collect stack/frame (dumps of anykind)
of a total system crash.
A total system crash would be experienced, for example, if
an event like a mouse click causes the system (Win98SE PC)
to go directly into a complete power off mode state, and
start to reboot - and thus there would be no difference
between a Dr. Watson log collected after bootup and one
collected prior to duplicating a problem, i.e. unless Dr.
Watson could collect a log of the event, which in my case,
it appears that Dr. Watson cannot, because the system
crashed, and Dr. Watson was not sufficiently in control to
the task.

When I try to look at my AV firewall logs during connection
to the Internet (via mouse click), I get a total system
crash. Any suggestions which lead to being able to capture
the stack/frame dump of this event will be much appreciated!

In the total system crash scenario - relative to Win98SE,
since Dr. Watson is classified as a 'postmortem debugger',
are there any product quality system level debuggers/tools
that can capture a total system crash stack/frame dump,
etc. and return control to the desktop without experiencing
the total system crash? For example, is there a SDK with a
suitable system crash tolerant debugger that I can download
for use in troubleshooting this problem?

Tia,

-- Tom

http://support.microsoft.com/default...b;en-us;275481
How to troubleshoot program faults with DrWatson

Likely, that won't answer your questions, though.

| When I try to look at my AV firewall logs during connection
| to the Internet (via mouse click), I get a total system
| crash.

Have you un/re-installed it? I guess, they may have something on their
web site about it. Are you sure you are supposed to be able to look at
them while connected to the NET & they are still works in progress?


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

"Tom" wrote in message
...
| Would someone please verify the following understanding I
| have about Dr. Watson use within Win98SE, and suggest a way
| to troubleshoot the problem described:
|
| 1) Dr. Watson CAN collect stack/frame (minidumps) of a
| program fault.
| A program fault, as I understand the use of Dr. Watson, is
| where an application program causes a (minidump) to be
| captured, and the system stays up and the Dr. Watson log of
| the event can be collected. From what I have read at the
| Microsoft site, this is what happens when Dr. Watson is
| able to collect a log of a program fault event.
|
| 2) Dr. Watson CANNOT collect stack/frame (dumps of anykind)
| of a total system crash.
| A total system crash would be experienced, for example, if
| an event like a mouse click causes the system (Win98SE PC)
| to go directly into a complete power off mode state, and
| start to reboot - and thus there would be no difference
| between a Dr. Watson log collected after bootup and one
| collected prior to duplicating a problem, i.e. unless Dr.
| Watson could collect a log of the event, which in my case,
| it appears that Dr. Watson cannot, because the system
| crashed, and Dr. Watson was not sufficiently in control to
| the task.
|
| When I try to look at my AV firewall logs during connection
| to the Internet (via mouse click), I get a total system
| crash. Any suggestions which lead to being able to capture
| the stack/frame dump of this event will be much appreciated!
|
| In the total system crash scenario - relative to Win98SE,
| since Dr. Watson is classified as a 'postmortem debugger',
| are there any product quality system level debuggers/tools
| that can capture a total system crash stack/frame dump,
| etc. and return control to the desktop without experiencing
| the total system crash? For example, is there a SDK with a
| suitable system crash tolerant debugger that I can download
| for use in troubleshooting this problem?
|
| Tia,
|
| -- Tom
|

Yes, I have uninstalled/reinstalled the AV, and I was
always able to previously look at the firewall logs while
connected.

Is there an SDK system level debugger capable of retaining
control in this situation? Dr. Watson appears to only be
able to debug program faults, not system crashes.

-- Tom

-----Original Message-----
http://support.microsoft.com/default...b;en-us;275481
How to troubleshoot program faults with DrWatson

Likely, that won't answer your questions, though.

| When I try to look at my AV firewall logs during connection
| to the Internet (via mouse click), I get a total system
| crash.

Have you un/re-installed it? I guess, they may have
something on their
web site about it. Are you sure you are supposed to be
able to look at
them while connected to the NET & they are still works in
progress?


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

"Tom" wrote in message
...
| Would someone please verify the following understanding I
| have about Dr. Watson use within Win98SE, and suggest a way
| to troubleshoot the problem described:
|
| 1) Dr. Watson CAN collect stack/frame (minidumps) of a
| program fault.
| A program fault, as I understand the use of Dr. Watson, is
| where an application program causes a (minidump) to be
| captured, and the system stays up and the Dr. Watson log of
| the event can be collected. From what I have read at the
| Microsoft site, this is what happens when Dr. Watson is
| able to collect a log of a program fault event.
|
| 2) Dr. Watson CANNOT collect stack/frame (dumps of anykind)
| of a total system crash.
| A total system crash would be experienced, for example, if
| an event like a mouse click causes the system (Win98SE PC)
| to go directly into a complete power off mode state, and
| start to reboot - and thus there would be no difference
| between a Dr. Watson log collected after bootup and one
| collected prior to duplicating a problem, i.e. unless Dr.
| Watson could collect a log of the event, which in my case,
| it appears that Dr. Watson cannot, because the system
| crashed, and Dr. Watson was not sufficiently in control to
| the task.
|
| When I try to look at my AV firewall logs during connection
| to the Internet (via mouse click), I get a total system
| crash. Any suggestions which lead to being able to capture
| the stack/frame dump of this event will be much appreciated!
|
| In the total system crash scenario - relative to Win98SE,
| since Dr. Watson is classified as a 'postmortem debugger',
| are there any product quality system level debuggers/tools
| that can capture a total system crash stack/frame dump,
| etc. and return control to the desktop without experiencing
| the total system crash? For example, is there a SDK with a
| suitable system crash tolerant debugger that I can download
| for use in troubleshooting this problem?
|
| Tia,
|
| -- Tom
|


.

There is a vast variety of debugging tools available. However, without
access to the source code how are you going to know which module, and where
in the module, you should be placing your breakpoints? What you are
attempting is impractical and I don't know of any circumstance in which
anyone other than a MS programmer would actually attempt to solve the
problem in this way.

What does the firewall provider say about this error?

Why not just look at your logs offline?
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Tom" wrote in message
...
Yes, I have uninstalled/reinstalled the AV, and I was
always able to previously look at the firewall logs while
connected.

Is there an SDK system level debugger capable of retaining
control in this situation? Dr. Watson appears to only be
able to debug program faults, not system crashes.

As Richards says, it will be tough to do as you propose. Are you
prepared to re-write AV, even should you discover which module is at
fault?

There is another free one to try...
http://www.avast.com/eng/avast_4_home.html Avast (free)
....which is the one I will go for the day McAfee dies or starts to
charge me.


--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
should things get worse after this,
PCR

"Tom" wrote in message
...
| Yes, I have uninstalled/reinstalled the AV, and I was
| always able to previously look at the firewall logs while
| connected.
|
| Is there an SDK system level debugger capable of retaining
| control in this situation? Dr. Watson appears to only be
| able to debug program faults, not system crashes.
|
| -- Tom
|
| -----Original Message-----
| http://support.microsoft.com/default...b;en-us;275481
| How to troubleshoot program faults with DrWatson
|
| Likely, that won't answer your questions, though.
|
| | When I try to look at my AV firewall logs during connection
| | to the Internet (via mouse click), I get a total system
| | crash.
|
| Have you un/re-installed it? I guess, they may have
| something on their
| web site about it. Are you sure you are supposed to be
| able to look at
| them while connected to the NET & they are still works in
| progress?
|
|
| --
| Thanks or Good Luck,
| There may be humor in this post, and,
| Naturally, you will not sue,
| should things get worse after this,
| PCR
|
| "Tom" wrote in message
| ...
| | Would someone please verify the following understanding I
| | have about Dr. Watson use within Win98SE, and suggest a way
| | to troubleshoot the problem described:
| |
| | 1) Dr. Watson CAN collect stack/frame (minidumps) of a
| | program fault.
| | A program fault, as I understand the use of Dr. Watson, is
| | where an application program causes a (minidump) to be
| | captured, and the system stays up and the Dr. Watson log of
| | the event can be collected. From what I have read at the
| | Microsoft site, this is what happens when Dr. Watson is
| | able to collect a log of a program fault event.
| |
| | 2) Dr. Watson CANNOT collect stack/frame (dumps of anykind)
| | of a total system crash.
| | A total system crash would be experienced, for example, if
| | an event like a mouse click causes the system (Win98SE PC)
| | to go directly into a complete power off mode state, and
| | start to reboot - and thus there would be no difference
| | between a Dr. Watson log collected after bootup and one
| | collected prior to duplicating a problem, i.e. unless Dr.
| | Watson could collect a log of the event, which in my case,
| | it appears that Dr. Watson cannot, because the system
| | crashed, and Dr. Watson was not sufficiently in control to
| | the task.
| |
| | When I try to look at my AV firewall logs during connection
| | to the Internet (via mouse click), I get a total system
| | crash. Any suggestions which lead to being able to capture
| | the stack/frame dump of this event will be much appreciated!
| |
| | In the total system crash scenario - relative to Win98SE,
| | since Dr. Watson is classified as a 'postmortem debugger',
| | are there any product quality system level debuggers/tools
| | that can capture a total system crash stack/frame dump,
| | etc. and return control to the desktop without experiencing
| | the total system crash? For example, is there a SDK with a
| | suitable system crash tolerant debugger that I can download
| | for use in troubleshooting this problem?
| |
| | Tia,
| |
| | -- Tom
| |
|
|
| .
|

Thanks for the reply Jeff.

I am not interested in setting breakpoints - only in
identifying what module name is associated with the stack
frame in control when the crash occurs. The crux of the
situation is that Dr. Watson has no control in this
situation, otherwise, Dr. Watson would be able to capture a
minidump (small stack frame dump).

This begs the question - What SDK debuggers did the MS
developers use for Win98(SE)? That would be useful
perhaps. I would like to be able to run a system level
debugger under which I could run my AV and dumplicate the
problem that way without the system crashing in order to
get the information of interest.

For example, when I click on the mouse to view the firewall
event log, the mouse click itself must be captured by an AV
routine to handle which log to access. My current guess is
that there may be a problem with the firewall log file -
e.g. it may be too large to open, or have been corrupted
such that when the file is accessed at runtime - it
generates an error condition for which there is no system
level handler which results in the system crash.

Whether such a scenario is the responsibility of the AV
vendor or not, I am not prepared to say without evidence.

-- Tom

-----Original Message-----
There is a vast variety of debugging tools available.
However, without
access to the source code how are you going to know which
module, and where
in the module, you should be placing your breakpoints?
What you are
attempting is impractical and I don't know of any
circumstance in which
anyone other than a MS programmer would actually attempt
to solve the
problem in this way.

What does the firewall provider say about this error?

Why not just look at your logs offline?
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Tom" wrote in message
...
Yes, I have uninstalled/reinstalled the AV, and I was
always able to previously look at the firewall logs while
connected.

Is there an SDK system level debugger capable of retaining
control in this situation? Dr. Watson appears to only be
able to debug program faults, not system crashes.


.

I think you have a somewhat distorted view of the way the system works. The
AV program knows nothing about mouses and mouse clicks - that is entirely
the responsibility of Windows. The AV program will process messages that
Windows sends, and some of those messages will contain information about
mouse clicks that have occurred, so if you could locate the message loop in
the AV program and if you could insert your breakpoint there then you could
trap each message and take a guess at which ones related to the mouse clicks
you were concerned with and step through their processing. But even if you
managed that, without the source code you wouldn't know where the process
went wrong, and the chance of finding the error is negligible. You don't
even know that the error is occurring inside the AV program, and not in some
other process that is also reading the AV program's messages.

Like I said, it's just not a practical way to track down this sort of error.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Tom" wrote in message
...
Thanks for the reply Jeff.

I am not interested in setting breakpoints - only in
identifying what module name is associated with the stack
frame in control when the crash occurs. The crux of the
situation is that Dr. Watson has no control in this
situation, otherwise, Dr. Watson would be able to capture a
minidump (small stack frame dump).

This begs the question - What SDK debuggers did the MS
developers use for Win98(SE)? That would be useful
perhaps. I would like to be able to run a system level
debugger under which I could run my AV and dumplicate the
problem that way without the system crashing in order to
get the information of interest.

For example, when I click on the mouse to view the firewall
event log, the mouse click itself must be captured by an AV
routine to handle which log to access. My current guess is
that there may be a problem with the firewall log file -
e.g. it may be too large to open, or have been corrupted
such that when the file is accessed at runtime - it
generates an error condition for which there is no system
level handler which results in the system crash.

Whether such a scenario is the responsibility of the AV
vendor or not, I am not prepared to say without evidence.

-- Tom

-----Original Message-----
There is a vast variety of debugging tools available.
However, without
access to the source code how are you going to know which
module, and where
in the module, you should be placing your breakpoints?
What you are
attempting is impractical and I don't know of any
circumstance in which
anyone other than a MS programmer would actually attempt
to solve the
problem in this way.

What does the firewall provider say about this error?

Why not just look at your logs offline?
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Tom" wrote in message
...
Yes, I have uninstalled/reinstalled the AV, and I was
always able to previously look at the firewall logs while
connected.

Is there an SDK system level debugger capable of retaining
control in this situation? Dr. Watson appears to only be
able to debug program faults, not system crashes.


.

Yeah, I agree that was phrased poorly. So, what practical
way would you advise to track down this sort of error given
the limited debugging/dumping facilities of Win98SE?

-----Original Message-----
I think you have a somewhat distorted view of the way the
system works. The
AV program knows nothing about mouses and mouse clicks -
that is entirely
the responsibility of Windows. The AV program will process
messages that
Windows sends, and some of those messages will contain
information about
mouse clicks that have occurred, so if you could locate
the message loop in
the AV program and if you could insert your breakpoint
there then you could
trap each message and take a guess at which ones related
to the mouse clicks
you were concerned with and step through their processing.
But even if you
managed that, without the source code you wouldn't know
where the process
went wrong, and the chance of finding the error is
negligible. You don't
even know that the error is occurring inside the AV
program, and not in some
other process that is also reading the AV program's messages.

Like I said, it's just not a practical way to track down
this sort of error.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Tom" wrote in message
...
Thanks for the reply Jeff.

I am not interested in setting breakpoints - only in
identifying what module name is associated with the stack
frame in control when the crash occurs. The crux of the
situation is that Dr. Watson has no control in this
situation, otherwise, Dr. Watson would be able to capture a
minidump (small stack frame dump).

This begs the question - What SDK debuggers did the MS
developers use for Win98(SE)? That would be useful
perhaps. I would like to be able to run a system level
debugger under which I could run my AV and dumplicate the
problem that way without the system crashing in order to
get the information of interest.

For example, when I click on the mouse to view the firewall
event log, the mouse click itself must be captured by an AV
routine to handle which log to access. My current guess is
that there may be a problem with the firewall log file -
e.g. it may be too large to open, or have been corrupted
such that when the file is accessed at runtime - it
generates an error condition for which there is no system
level handler which results in the system crash.

Whether such a scenario is the responsibility of the AV
vendor or not, I am not prepared to say without evidence.

-- Tom

-----Original Message-----
There is a vast variety of debugging tools available.
However, without
access to the source code how are you going to know which
module, and where
in the module, you should be placing your breakpoints?
What you are
attempting is impractical and I don't know of any
circumstance in which
anyone other than a MS programmer would actually attempt
to solve the
problem in this way.

What does the firewall provider say about this error?

Why not just look at your logs offline?
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Tom" wrote in message
.. .
Yes, I have uninstalled/reinstalled the AV, and I was
always able to previously look at the firewall logs while
connected.

Is there an SDK system level debugger capable of retaining
control in this situation? Dr. Watson appears to only be
able to debug program faults, not system crashes.


.



.

Contact the manufacturer to see if they are aware of the problem. Avoid the
issue by examining the log files off line. Use a formal problem diagnosis
procedure such as :
http://support.microsoft.com/?kbid=192926
How to Perform Clean-Boot Troubleshooting for Windows 98
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Tom" wrote in message
...
Yeah, I agree that was phrased poorly. So, what practical
way would you advise to track down this sort of error given
the limited debugging/dumping facilities of Win98SE?

-----Original Message-----
I think you have a somewhat distorted view of the way the
system works. The
AV program knows nothing about mouses and mouse clicks -
that is entirely
the responsibility of Windows. The AV program will process
messages that
Windows sends, and some of those messages will contain
information about
mouse clicks that have occurred, so if you could locate
the message loop in
the AV program and if you could insert your breakpoint
there then you could
trap each message and take a guess at which ones related
to the mouse clicks
you were concerned with and step through their processing.
But even if you
managed that, without the source code you wouldn't know
where the process
went wrong, and the chance of finding the error is
negligible. You don't
even know that the error is occurring inside the AV
program, and not in some
other process that is also reading the AV program's messages.

Like I said, it's just not a practical way to track down
this sort of error.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Tom" wrote in message
...
Thanks for the reply Jeff.

I am not interested in setting breakpoints - only in
identifying what module name is associated with the stack
frame in control when the crash occurs. The crux of the
situation is that Dr. Watson has no control in this
situation, otherwise, Dr. Watson would be able to capture a
minidump (small stack frame dump).

This begs the question - What SDK debuggers did the MS
developers use for Win98(SE)? That would be useful
perhaps. I would like to be able to run a system level
debugger under which I could run my AV and dumplicate the
problem that way without the system crashing in order to
get the information of interest.

For example, when I click on the mouse to view the firewall
event log, the mouse click itself must be captured by an AV
routine to handle which log to access. My current guess is
that there may be a problem with the firewall log file -
e.g. it may be too large to open, or have been corrupted
such that when the file is accessed at runtime - it
generates an error condition for which there is no system
level handler which results in the system crash.

Whether such a scenario is the responsibility of the AV
vendor or not, I am not prepared to say without evidence.

-- Tom

-----Original Message-----
There is a vast variety of debugging tools available.
However, without
access to the source code how are you going to know which
module, and where
in the module, you should be placing your breakpoints?
What you are
attempting is impractical and I don't know of any
circumstance in which
anyone other than a MS programmer would actually attempt
to solve the
problem in this way.

What does the firewall provider say about this error?

Why not just look at your logs offline?
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Tom" wrote in message
. ..
Yes, I have uninstalled/reinstalled the AV, and I was
always able to previously look at the firewall logs while
connected.

Is there an SDK system level debugger capable of retaining
control in this situation? Dr. Watson appears to only be
able to debug program faults, not system crashes.


.



.

Thansk Jeff, I'll give that a try

-----Original Message-----
Contact the manufacturer to see if they are aware of the
problem. Avoid the
issue by examining the log files off line. Use a formal
problem diagnosis
procedure such as :
http://support.microsoft.com/?kbid=192926
How to Perform Clean-Boot Troubleshooting for Windows 98
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Tom" wrote in message
...
Yeah, I agree that was phrased poorly. So, what practical
way would you advise to track down this sort of error given
the limited debugging/dumping facilities of Win98SE?

-----Original Message-----
I think you have a somewhat distorted view of the way the
system works. The
AV program knows nothing about mouses and mouse clicks -
that is entirely
the responsibility of Windows. The AV program will process
messages that
Windows sends, and some of those messages will contain
information about
mouse clicks that have occurred, so if you could locate
the message loop in
the AV program and if you could insert your breakpoint
there then you could
trap each message and take a guess at which ones related
to the mouse clicks
you were concerned with and step through their processing.
But even if you
managed that, without the source code you wouldn't know
where the process
went wrong, and the chance of finding the error is
negligible. You don't
even know that the error is occurring inside the AV
program, and not in some
other process that is also reading the AV program's
messages.

Like I said, it's just not a practical way to track down
this sort of error.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Tom" wrote in message
.. .
Thanks for the reply Jeff.

I am not interested in setting breakpoints - only in
identifying what module name is associated with the stack
frame in control when the crash occurs. The crux of the
situation is that Dr. Watson has no control in this
situation, otherwise, Dr. Watson would be able to
capture a
minidump (small stack frame dump).

This begs the question - What SDK debuggers did the MS
developers use for Win98(SE)? That would be useful
perhaps. I would like to be able to run a system level
debugger under which I could run my AV and dumplicate the
problem that way without the system crashing in order to
get the information of interest.

For example, when I click on the mouse to view the
firewall
event log, the mouse click itself must be captured by
an AV
routine to handle which log to access. My current
guess is
that there may be a problem with the firewall log file -
e.g. it may be too large to open, or have been corrupted
such that when the file is accessed at runtime - it
generates an error condition for which there is no system
level handler which results in the system crash.

Whether such a scenario is the responsibility of the AV
vendor or not, I am not prepared to say without evidence.

-- Tom

-----Original Message-----
There is a vast variety of debugging tools available.
However, without
access to the source code how are you going to know which
module, and where
in the module, you should be placing your breakpoints?
What you are
attempting is impractical and I don't know of any
circumstance in which
anyone other than a MS programmer would actually attempt
to solve the
problem in this way.

What does the firewall provider say about this error?

Why not just look at your logs offline?
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Tom" wrote in
message
.. .
Yes, I have uninstalled/reinstalled the AV, and I was
always able to previously look at the firewall logs
while
connected.

Is there an SDK system level debugger capable of
retaining
control in this situation? Dr. Watson appears to
only be
able to debug program faults, not system crashes.


.



.



.