IE6: Help Engine Sputtering, Main Engine Doesn't Start, Segmentation Fault - wine-devel

17 Oct 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