(cross-post added to Vista Perf & Maint)
"Melelina" wrote in message
...
Application Name: iexplore.exe
Application Version: 8.0.6001.17184
Application Timestamp: 47ccc78e
Fault Module Name: mshtml.dll
Fault Module Version: 8.0.6001.17184
Fault Module Timestamp: 47ccc7ab
Exception Code: c0000005
Exception Offset: 00159044


I would like to know how to see a Stack Back Trace in Vista.
Crash "signatures" consisting of nothing but the crash offset
in normally robust modules don't seem very helpful to me.

FYI today I found out that Process Explorer has a way to
dump a thread's Stack. Who knew? I found it while trying
to analyse a crash in WLMail. Although the crashing thread
seemed to be suspended by spawning a DW20.EXE thread
it wasn't clear to me how to identify the crashing thread or whether
even if I guessed at the right one, that thread's stack list would be
sufficiently related to the crash to be useful. Still, it makes me
hopeful that eventually we will be able to find a useful way of
better documenting crashes in these newsgroups.

Another enticing possibility that this technique might include
is making Process Explorer aware of the relevant symbols.
Then we'd really get some clues about our crashes... ; )


OS Version: 6.0.6000.2.0.0.256.1
Locale ID: 1033
Additional Information 1: 8d13
Additional Information 2: cdca9b1d21d12b77d84f02df48e34311
Additional Information 3: 8d13
Additional Information 4: cdca9b1d21d12b77d84f02df48e34311


IE 8 crashes after just a couple of minutes on Vista (no SP1). If I allow it
to restart, it crashes again almost immediately. It wasn't doing this when
first installed several weeks ago when I first installed Vista Ultimate to a
Virtual PC.


Almost certainly this is being caused by interference
from third-party modules. The problem is identifying them
and eliminating them. That's the whole idea of IE7's
"No Add-ons Mode" (e.g. Run... iexplore.exe -extoff)
So, then if an otherwise reproducible symptom does
not recur, you can start trying to isolate individual add-ons
(e.g. using the Manage Add-ons tool).


I also have IE 8 installed on an XPPro SP2 virtual machine and it doesn't
crash on that machine (but it is barely useable for other reasons).

And probably doesn't have the same set of add-ons either... ; )


HTH

Robert Aldwinckle
---

I figured out what was causing the crashing. It was the Proxomitron (local
proxy server). I should have thought of it right away I suppose because the
configs I use for it are not tested for a browser only in beta1. Proxo is so
much a part of my browsing though (six years I have used it and before it
Ad/Subtract which uses licensed Proxo code) that I don't quickly think about
it maybe being the culprit in some problem. When I bypassed it the crashing
stopped. It was some interaction between my home page
www.dslreports.com/postlist, Proxo filters, Vista, and IE8 causing the
problem. I can notify the Proxo config author but that seems premature to
me considering IE8 is only in beta 1. If the problem persists in beta 2, I
will let him know. Of course, I use Proxo on all my computers and I have
not experienced IE8 crashing on my XP Pro SP2 virtual machine when accessing
my home page. This appears to be a Vista only problem.

"Robert Aldwinckle" wrote in message
...
(cross-post added to Vista Perf & Maint)
"Melelina" wrote in message
...
Application Name: iexplore.exe
Application Version: 8.0.6001.17184
Application Timestamp: 47ccc78e
Fault Module Name: mshtml.dll
Fault Module Version: 8.0.6001.17184
Fault Module Timestamp: 47ccc7ab
Exception Code: c0000005
Exception Offset: 00159044


I would like to know how to see a Stack Back Trace in Vista.
Crash "signatures" consisting of nothing but the crash offset
in normally robust modules don't seem very helpful to me.

FYI today I found out that Process Explorer has a way to
dump a thread's Stack. Who knew? I found it while trying
to analyse a crash in WLMail. Although the crashing thread
seemed to be suspended by spawning a DW20.EXE thread
it wasn't clear to me how to identify the crashing thread or whether
even if I guessed at the right one, that thread's stack list would be
sufficiently related to the crash to be useful. Still, it makes me
hopeful that eventually we will be able to find a useful way of
better documenting crashes in these newsgroups.

Another enticing possibility that this technique might include
is making Process Explorer aware of the relevant symbols.
Then we'd really get some clues about our crashes... ; )


OS Version: 6.0.6000.2.0.0.256.1
Locale ID: 1033
Additional Information 1: 8d13
Additional Information 2: cdca9b1d21d12b77d84f02df48e34311
Additional Information 3: 8d13
Additional Information 4: cdca9b1d21d12b77d84f02df48e34311


IE 8 crashes after just a couple of minutes on Vista (no SP1). If I allow
it
to restart, it crashes again almost immediately. It wasn't doing this
when
first installed several weeks ago when I first installed Vista Ultimate
to a
Virtual PC.


Almost certainly this is being caused by interference
from third-party modules. The problem is identifying them
and eliminating them. That's the whole idea of IE7's
"No Add-ons Mode" (e.g. Run... iexplore.exe -extoff)
So, then if an otherwise reproducible symptom does
not recur, you can start trying to isolate individual add-ons
(e.g. using the Manage Add-ons tool).


I also have IE 8 installed on an XPPro SP2 virtual machine and it doesn't
crash on that machine (but it is barely useable for other reasons).

And probably doesn't have the same set of add-ons either... ; )


HTH

Robert Aldwinckle
---

"Melelina" wrote in message
...
I figured out what was causing the crashing. It was the Proxomitron
(local proxy server).
....
This appears to be a Vista only problem.


Thanks for sharing the resolution.


....
Almost certainly this is being caused by interference
from third-party modules. The problem is identifying them
and eliminating them. That's the whole idea of IE7's
"No Add-ons Mode" (e.g. Run... iexplore.exe -extoff)
So, then if an otherwise reproducible symptom does
not recur, you can start trying to isolate individual add-ons
(e.g. using the Manage Add-ons tool).


So, let me guess: No Add-ons mode doesn't block that one? eg
Unfortunately No Add-ons mode can't completely replace
standard clean-boot troubleshooting techniques...

; )




I also have IE 8 installed on an XPPro SP2 virtual machine and it doesn't
crash on that machine (but it is barely useable for other reasons).

And probably doesn't have the same set of add-ons either... ; )


HTH

Robert Aldwinckle
---