Have you disabled the Error Reporting Tool? (Ref.
<title>Description and availability of Internet Explorer Error Reporting tool</title>
http://support.microsoft.com/kb/276550
E.g. if there is a [click here] link in the message window use it.
It would lead you to a capturable Error Signature. (E.g. doubleclick
on a word, then Ctrl-a, Ctrl-c there.)
Please pay closer attention to what I said:
>> Run... ProcMon. It will capture an entry for your crash and you will be able
>> to extract from it a list of the modules involved in the call stack at the time
>> of the crash. That could be an easier alternative the more conventional
>> analysis of the Stack Back Trace for the crashing thread (e.g. as found
>> below the FAULT -> line in the associated drwtsn32.log dump.)
I'm suggesting only that you find the one entry which represents your crash event.
Then open that entry and you will see as I wrote: "a list of the modules involved
in the call stack at the time of the crash". The alternative to getting the call stack
that way is the more conventional Stack Back Trace provided by drwtsn32.log
E.g. that would probably be the last instance of wuauclt.exe in your trace,
probably one which contains the crash address (which you are seeing somehow).
BTW you probably also should check the Application tab in the Event Viewer
to see if there is a corresponding crash record in there.
The fact that you do see it means that you have something to search for,
which should make it relatively easy to find. I'm not sure if ProcMon reports
a 0x prefix on all its addresses so omit that when doing your find.
(FYI) You are posting to an NNTP news server. So if you were using a real NNTP
news reader (such as Outlook Express) you could upload files as attachments.
However, that would only be appropriate for small files, unless you posted
them in a message to a test newsgroup and then notified your readers how to find it.
That header line from your post shows that your "news reader"
is MS web interface to NNTP newsgroups. There is no provision
for posting attachments through it. Some such users find web
solutions to that problem and provide links to the files on third-party
servers.
I don't think that much would be accepted as attachments on this server
even if you did post it in a test newsgroup.
I'm still curious to know if you ever get a module loaded at 0x60750000
and if so what it is. ProcMon might help you find that too.
E.g. just capture all wuauclt.exe's activity, then do a find for 60750000.
(Actually, considering how close the crash is to that address perhaps
you should be looking instead for a module which loads at 0x60740000.)
Provided that (hypothetical) module gets loaded and then sticks around
long enough for you to see it loaded before your crash, you could alternatively
obtain that detail using Process Explorer.
I.e. I suspect that the crash address represents an offset in a third-party
module which was previously loaded. As I mentioned previously it is not
a base address that I see used in my wuauclt.exe (via Process Explorer).
If you knew which module it was you might have a better chance of eliminating
it as a source of interference and then at least changing your problem symptom.
However you get a list of the other modules loaded under wuauclt.exe
(but ideally with their routine names in the order that they were used
leading up to the crash--i.e. the call stack) would show us the callers
which were involved in the crash.
Reply With Quote
Bookmarks