Re: wuauclt.exe has encountered a problem...

"SithMonkey7" <SithMonkey7@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:B5EDE2F7-C1BA-43A0-8E16-5FD664172470@xxxxxxxxxxxxxxxx
Hi Robert and thanks for your reply. The error does not indicate which
program or module is involved. That is the full extent of the message and pop-up detail.


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.)


I did run a couple of procmon files, but they are ginormous
to say the least. I am not really sure what I'm looking for in the log to
snip it out.


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.


Additionally, I'm not seeing that I can upload any files to the
forum here (I'm new, maybe I'm missing it).


(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.

[X-Newsreader: Microsoft CDO for Windows 2000]

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.


The smallest file I have is 88,012KB uncompressed, 9.55MB zipped.

I don't think that much would be accepted as attachments on this server
even if you did post it in a test newsgroup.


What can I provide that would be useful and how?

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.



Many Thanks,
Brian


Good luck

Robert
---


.

Relevant Pages

  • Re: a dozen cpus on a chip
    ... It is still possible to write something that will crash, ... memory, or write to memory it doesn't own should be terminated with a ... I think that hardware designers could do a lot to improve matters. ... Having a call-return stack, a parameter stack, return value area, and ...
    (sci.electronics.design)
  • Re: boot failure, "DWARF2 unwinder stuck at 0xc0100199"
    ... The way that code reads the stack is just ... this unwinder change has been quite problematic. ... add new crashes and the fallback always gives an useful backtrace (that is why I ... Has anyone even tried to reproduce Bruce's crash? ...
    (Linux-Kernel)
  • Win32 DLL project randomly crashes after moving to VS2005
    ... the first step was to take care of the compilation ... The problem is that when I run my DLL it crashes in apparently random places ... I had a crash within a dialog's window procedure and another ... image library were generating a "stack overflow" message. ...
    (microsoft.public.vc.ide_general)
  • Re: Bugcheck 101
    ... This is what the stack in the hung processor looks like: ... The bugcheck information should show the hung processor. ... the crash, and all 8 virtual processors are busy at that time. ... waiting for a timer interrupt, and while processor 3 is the timed out ...
    (microsoft.public.development.device.drivers)
  • Win32 DLL project randomly crashes after moving to VS2005
    ... the first step was to take care of the compilation ... The problem is that when I run my DLL it crashes in apparently random places ... I had a crash within a dialog's window procedure and another ... image library were generating a "stack overflow" message. ...
    (microsoft.public.vstudio.general)