Re: How to debug & resolve constant gsview crash on pstoedit.dll

de B. R. 'BeAr' Ederson 01/30/2008 08:11

> On Tue, 29 Jan 2008 13:02:29 -0800 (PST), software.installer@yahoo.com
> wrote:
>
[Crash in pstoedit.dll - Offset: 0008e8c2 - when called from GSView]
>
> For a start you may <Profile> the conversation process using
> Dependency Walker from here:
>
> http://www.dependencywalker.com
>
> It's a bit late here to check the underlying code of the offset you
> provided. Maybe tomorrow... ;-)

Seems, "tomorrow" has now come to pass. ;-) So there you are:

The pstoedit.dll you linked to has inconsistent header information.
The crash offset points to data section, not code.

>> This happens only on one system. I can't see what's different on
>> this system.

If you really have the *same* (neither a newer nor older) version of
pstoedit.dll on different systems and the crash only occurs on one,
it might be worth to investigate further. Else I'd just think the
current release buggy.

[Dr. Watson log file]
>> C:added proggiesadded converterspstoeditpstoedit.dll
>> function: pstoedit!DriverDescription__currentfilename

Reference to internal or external conversation plugin. (Can be both
from source code.) Crash could have many causes. If we put aside
the possibility of a faulty pstoedit.dll (which isn't unlikely) for
the moment, you should try another installation in a near top-level
directory without spaces in the name. Add all relevant directories
to search path, execute with virus scanner disabled, log file and
registry access with Process Monitor from Sysinternals,...

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

But beforehand, I'd suggest you give the <Profiling> option of
Dependency Walker (see citation of my last mail above) a try.
Just by loading the pstoedit.dll with Dependency Walker you can
see if any directly referenced imports are missing.

And by profiling GSView with a complete conversion attempt you may
see additional errors and the functionality accessed directly before
the crash.

Creating and analyzing a memory dump (like Johnw suggested) is also
a good way to pin the problem. The user.dmp file you had on your
disk belongs to an older crash, though. You need to get a new one
written.

Good luck with you failure search!

BeAr
--
===========================================================================
= What do you mean with: "Perfection is always an illusion"? =
===============================================================--(Oops!)===