If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
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 |
#3
|
|||
|
|||
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 | . |
#4
|
|||
|
|||
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. |
#5
|
|||
|
|||
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 | | | | | . | |
#6
|
|||
|
|||
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. . |
#7
|
|||
|
|||
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. . |
#8
|
|||
|
|||
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. . . |
#9
|
|||
|
|||
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. . . |
#10
|
|||
|
|||
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. . . . |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Adding Fonts to Win98se & Win95a | ForestSpirit | General | 1 | January 16th 05 10:40 PM |
Puzzle: Win98SE Version and USB Flash Drive Security Application | Alan Raskin | General | 10 | January 9th 05 05:23 AM |
Running WIN98SE with 4GB DDR and RAID | Paul Leon | General | 2 | October 5th 04 03:25 AM |
Win98se RAM problems SOLVED! | Cloaked | Setup & Installation | 5 | September 15th 04 10:44 PM |
upgrade from win98 to win98se | bob engler | General | 1 | July 24th 04 06:20 AM |