IE6: Help Engine Sputtering, Main Engine Doesn't Start, Segmentation
Fault
Dan McGhee
farmerdan at i-rule.net
Sun Oct 17 12:15:00 CDT 2004
At the outset I must apologize for the length of this post. This
situation is intricately convoluted and, currently, I cannot interpret
the information that I have collected. Right now I can only relay
information that I think is relevant. I would be more than happy to
generate more info, but I will need some specific direction for commands
and so forth. Right now I have reached the limit of my current
troubleshooting skills.
My overall goal is to get Edit Studio 4, a video editing application,
running in wine. It depends on the IE6 Help Engine. There are other
situations with this app and that's why I don't depend on an older
version of wine to run it. Right now, if I can't get IE6 to run its
help engine, I can't get my app to work. Here goes on my problems with IE6.
Conventions:
1013 implies wine compiled from the cvs update on October 13 and a
.wine, created from that update
aug implies wine version compiled from the cvs update on October 13
and a .wine from a wine version, compiled from my repository, before
the 20040824 16:00:16 CDT commit
Symptoms:
1. with wine from 1013 and .wine from 1013, IE6 exits with no
window--this started sometime after the
September snapshot
2. with wine from 1013, any version of wine that I compile, and
.wine from aug, IE6 runs and Help works
3. with wine from September snapshot and .wine from 1013, IE6
creates a segmentation fault
My original symptom was that I couldn't get IE6 Help to work after the
September snapshot. I did a regression and identified the commit of
20040824 16:00:16 CDT as causing the problem. The commit edits this patch:
http://cvs.winehq.org/patch.py?id=13475
Among other things this patch changes
wine/dlls/Makefile.in
wine/configure.ac
wine/configure
it also changes itss.dll. However, my symptoms still persist whether I
use a native or builtin version of itss. I include this information
because I don't know if the symptoms are separate problems or are related.
I am not able to pin point the cause of Symptom 1 because I do not yet
know how to update my repository to do a regression. I must wait for
the archive after the October snapshot.
I have reasoned, since I can get IE6 to work completely using a ~/.wine
created before that August commit, that the problem lies somewhere in
the "fake windows" directory. There are differences in the registry,
win.ini and system.ini files, but I do not know how to diagnose them.
The following excerpt, from one of the logs I created, shows that there
is a completely different sequence, between the working and non-working
situations, when shell32 loads for the first time:
trace:loaddll:load_dll Loaded module
L"c:\\windows\\system\\shell32.dll" : builtin
-trace:loaddll:MODULE_FlushModrefs Unloaded module
L"c:\\windows\\system\\shell32.dll" : builtin
-trace:loaddll:load_dll Loaded module
L"c:\\windows\\system\\shell32.dll" : builtin
trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\ole32.dll"
: native
trace:loaddll:load_dll Loaded module
L"C:\\windows\\system\\BROWSEUI.dll" : native
err:shell:ReadCabinetState Initializing shell cabinet settings
trace:loaddll:load_dll Loaded module
L"C:\\windows\\system\\browselc.dll" : native
-trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\RPCRT4.DLL"
: native
+trace:loaddll:load_dll Loaded module
L"C:\\windows\\system\\shdoclc.dll" : native
+err:rebar:REBAR_WindowProc unknown msg 200b wp=00000000 lp=71180f00
+trace:loaddll:load_dll Loaded module
L"c:\\windows\\system\\uxtheme.dll" : builtin
+trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\RPCRT4.dll"
: native
+trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\lz32.dll" :
builtin
+trace:loaddll:load_dll Loaded module
L"c:\\windows\\system\\version.dll" : builtin
+trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\urlmon.dll"
: native
trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\MSOSS.dll"
: native
trace:loaddll:load_dll Loaded module
L"C:\\windows\\system\\CRYPT32.dll" : native
trace:loaddll:load_dll Loaded module
L"C:\\windows\\system\\OLEAUT32.dll" : native
trace:loaddll:load_dll Loaded module
L"C:\\windows\\system\\WININET.dll" : native
I stopped the excerpt here because this is the point at which the
non-working situation exits. I have generated a log from +relay
"grepped" for shell32 but do not know how to interpret it to see if I
can glean any more information. This log and all the others are
contained in the tarball that I have attached. It creates a directory
called "wine-trouble" and contains all the information that I have
generated. The README contains specifics of what I have done.
As I was composing the README for inclusion here, I realized that I had
not done two things. I forgot to copy shell and shell32 to my fake
windows directory so that all of my tests were conducted with builtin
shell and shell32. Additionally, I have not run wine compiled before
the August commit with a fake windows created on October 13. I will do
both of these and see if I get differenet results.
I'm really interested in resolving this and would rather that I had been
able to supply better information. However, my knowlege of winedbg,
windows and cvs does not currently allow me to proceed further. If
anyone wants me to do more, I would appreciate being pointed in the
right direction, but I will need some specifics.
I have found no documentation on any of the wine mailing lists or other
forums to indicate that anyone else is having this problem. It could be
something that I am doing. This is why I haven't yet submitted a bug
report. If a bug report would be more appropriate, I will do that.
Thanks,
Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wine-trouble.tar.gz
Type: application/x-gzip
Size: 18961 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20041017/1c8ae2b7/wine-trouble.tar.bin
More information about the wine-devel
mailing list