Reading Debug Trace Examples
From Wine-Wiki
[edit] Reading Suspicious Traces
Identifying what went wrong can be almost an art, so here are some examples.
[edit] General Information
0009:Ret ws2_32.gethostbyname() retval=00000000 ret=004725f1 0009:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x4725f1
M.Hearn: Retval is what the functions result was. Ret is the code address that the function was called from. You can normally ignore it but it's useful for disassembly.
M. Hearn: a NULL return [ws2_32.gethostname() retval=00000000] means an error occurred.
warn:ntdll:NtCreateFile L"\\??\\C:\\Program Files\\origin6.0\\UNTITLED.OPJ" not found (c0000034)
A user noted the L"\\??\\" looks odd..
A. Julliard: The \??\ is the NT prefix, that's normal.Wine Archive
[edit] Video
0009:trace:ddraw:DIB_DirectDrawSurface_Blt (7ff307c8)->(0,0,0,01000400,7fd8fb44) 0009:trace:ddraw:DIB_DirectDrawSurface_Blt flags: DDBLT_COLORFILL DDBLT_WAIT=20 0009:warn:ddraw:DIB_DirectDrawSurface_Blt Surface is busy, returning DDERR_SURFACEBUSY 0009:trace:ddraw:DIB_DirectDrawSurface_Blt (7ff307c8)->(7fd8f708,0,0,01000400,7fd8f718) 0009:trace:ddraw:DIB_DirectDrawSurface_Blt destrect :0x0-794x550 0009:trace:ddraw:DIB_DirectDrawSurface_Blt flags: DDBLT_COLORFILL DDBLT_WAIT=20 0009:warn:ddraw:DIB_DirectDrawSurface_Blt Surface is busy, returning DDERR_SURFACEBUSY 0009:trace:ddraw:DIB_DirectDrawSurface_Blt (7ff307c8)->(7fd8f6e0,7ffeb6e0,7fd8f704,01000000,0) 0009:trace:ddraw:DIB_DirectDrawSurface_Blt destrect :155x135-651x215 0009:trace:ddraw:DIB_DirectDrawSurface_Blt srcrect :0x41-496x121 0009:trace:ddraw:DIB_DirectDrawSurface_Blt flags: DDBLT_WAIT=20 0009:warn:ddraw:DIB_DirectDrawSurface_Blt Surface is busy, returning DDERR_SURFACEBUSY 0009:trace:ddraw:DIB_DirectDrawSurface_Blt (7ff307c8)->(7fd8f6e0,7ffeb6e0,7fd8f704,01000000,0) 0009:trace:ddraw:DIB_DirectDrawSurface_Blt destrect :263x242-545x361 0009:trace:ddraw:DIB_DirectDrawSurface_Blt srcrect :0x125-282x244 0009:trace:ddraw:DIB_DirectDrawSurface_Blt flags: DDBLT_WAIT=20 0009:warn:ddraw:DIB_DirectDrawSurface_Blt Surface is busy, returning DDERR_SURFACEBUSY ****** 0009:warn:ddraw:DIB_DirectDrawSurface_Blt Application gave us bad source rectangle for Blt.
R. Lunnon: The instances of DDERR_SURFACEBUSY ...It looks suspiciously like the blt call didn't release the surface when the error occured.
Further investigation identified the problem. R. Lunnon: it's a ddraw problem with poor error handling, the surface wasn't released properly when the error "Application gave us bad source rectangle for Blt." occurs. Also the DIB_DirectDrawSurface_Blt fuction doesn't return error status captured during execution properly, preferring to return DD_OK all the time. Wine Archive Link
The stuck splash screen
A User reported a deadlock with a program freezing after displaying the splash screen
0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=00415bad 0009:Call ntdll.RtlLeaveCriticalSection(42020a64) ret=00415bb9 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=00415bb9 0009:Call ntdll.RtlUnwind(406fd0b8,0040359e,406fbe78,00000000) ret=0040359e fs=003b eax=406fbe78 ebx=406fb904 ecx=00411b4d edx=406fd0b8 esi=406fbe78 edi=401fd4f2 ebp=406fb920 esp=406fb8bc ds=007b es=007b gs=0033 flags=00000246 0009:Ret ntdll.RtlUnwind() retval=00000000 ret=0040359e fs=003b eax=00000000 ebx=406fb904 ecx=00411b4d edx=406fd0b8 esi=406fbe78 edi=401fd4f2 ebp=406fb920 esp=406fb8bc ds=007b es=007b gs=0033 flags=00000246
J. Hawkins: From the bit of log we have here, UpdateWindow and IsWindowVisible are being called, and we're getting a deadlock, well we're supposed to expect it :-) Can you run this command and pipe the output to another log file? We can use newlogfile[1,2] to see how often and where these calls are occurring. I can't tell if we're calling UpdateWindow and IsWindowVisible over and over again or not with this log, but post the new logs and we'll have a look.
g rep "UpdateWindow" oldlogfile > newlogfile1 gr ep "IsWindowVisible" oldlogfile > newlogfile2
M. Hearn: pointed to a part of the trace:
0009:Call ntdll.RtlUnwind(406fd0b8,0040359e,406fbe78,00000000) ret=0040359e
Can you do a +relay,+tid,+seh trace please? The problem seems to be that an exception is being thrown which unwinds past the USER syslevel - probably attempting to display an error box triggers the deadlock. Wine Archive Link
[edit] OpenGL
glStencilOp(...) @ device.c / 3809 fixme:d3d:IWineD3DDeviceImpl_SetRenderState >>>>>>>>>>>>>>>>> 500 from glStencilOp(...) @ device.c / 3809 fixme:d3d:IWineD3DDeviceImpl_SetRenderState >>>>>>>>>>>>>>>>> 500 from glStencilOp(...) @ device.c / 3809
S. Dossenger [Mar 06]: These are harmless, they are fixmes from the direct3d initialization. Some render states aren't supported by wines d3d implementation, but when wined3d initializes, it sets them to the default value, which causes such messages.
fixme:d3d:IWineD3DDeviceImpl_EvictManagedResources (0x4d290020) : stub
S. Dossenger [Mar 06]: EvictManagedTextures is a windows-related video memory management thing,and it won't have much impact too. If it has, then it will only show slightly reduced performance for a few secounds after loading. It should remove the managed textures from the video card, to make the memory free for new textures. [...] If you set
- Option "AGPMode" "4"
- Option "EnablePageFlip" "1"
- Option "BackingStore" "1"
in your device section of the dri driver, then the performance should be equal to fglrx(~2000 fps). If you install driconf and enable HyperZ, then you should get another boost. Alternatively, you can create a file /etc/drirc with the following content:
- <driconf>
- <device screen="0" driver="r200">
- <application name="all">
- <option name="arb_vertex_program" value="true" /> <option
- name="texture_level_hack" value="true" /> <option
- name="hyperz" value="true" />
- </application>
- <application name="all">
- </device>
- <device screen="0" driver="r200">
- </driconf>
The first option enables software emulated vertex shaders, but I don't know if they work. The secound option enables a hack which increases the maximum texture size by a factor of 4 (1024x1024 -> 2048x2048) if you have the dxtn decompression libary installed. google for libtxc_dxtn050908.tar.gz, it should be the first entry. Installing this library enables compressed textures too, which can improve the performance drastically in some games which support it. The "hyperz" option enables hyperz, which also increases the performance, especially in glxgears. With all the options enabled, I get about 3670 fps in glxgears(Acer travelmate 803, 1.6 Ghz pentium M, radeon mobility 9000, Xorg 7.0 with the dri driver). But again, glxgears isn't a benchmark. My experience is that the open source driver offers equal performance since Xorg 7.0, quite often it's faster, but only in unreal tournament 2004 it's significantly slower(general > 40fps, but sometimes only 15-20 fps, which makes it unplayable. [He then mentions he suspected a driver bug] wine archive
R. May: There is a problem with a menubar in an OpenGL program I use, WeatherScope. With Wine-20050211 and newer, the menubar is overdrawn by the OpenGL background color. I can still get the pop up menus to appear if I click the area where the menu should be. Also, if I switch focus to a different app, like an Xterm, the menubar will appear.
P. van Schayck May 2005: As far as I know this is a known problem after the [very recent] window rewrite. It required a hack to work before the rewrite. The hack was removed and now this happens with all opengl program with things like menubars. Wine Archive Link
J. Garvin: This bug still exists with the latest fglrx drivers and 0.9.2.
Xlib: extension "GLX" missing on display ":0.0". wine: Unhandled exception (thread 0009), starting debugger...
G. Hamill solved this for his computer: Install the nvidia non-free drivers and kernel module (enable Load "glx", disable Load "GLcore" and "Load "dri" in your XF86Config, and change driver "nv" to driver "nvidia")
T. Chilton had further difficulties: Unfortunately when I changed the driver to nvidia it stops X from loading properly (all I get is a blank screen with a cursor, which I am able to move).Also I'm using X11 not XFree86 if that makes sense.
The discussion ended .Wine Archive Link.
[edit] OLE
err:ole:CoGetClassObject class {00000100-0000-0010-8000-00aa006d2ea4} not registered
D. Timoshkov [aut 08 bug14858] try 'winetricks mdac25.
wine ESales.exe
err:ole:CoGetClassObject class {00000514-0000-0010-8000-00aa006d2ea4} not registered
err:ole:CoGetClassObject class {00000514-0000-0010-8000-00aa006d2ea4} not registered
err:ole:create_server class {00000514-0000-0010-8000-00aa006d2ea4} not registered
err:ole:CoGetClassObject no class object {00000514-0000-0010-8000-00aa006d2ea4} could be created for context 0x7
Error Code = 80040154 Code meaning = Unknown error 0x80040154 Source = (null) Description = (null)
Open dataSource error wuhaibo@wuhaibo-desktop:~/.wine/drive_c/Program Files/PASOFTS/ESales/bin$
Vitamin [Nov 08] Looks like ADO/MDAC: Code: w get http://www.kegel.com/wine/winetricks sh ./winetrics mdac25
fixme:ole:OLEPictureImpl_FindConnectionPoint no connection point for{33ad4ed2-6699-11cf-b70c-00aa0060d393}
A poster asked what this was: Anyone know?
R. Shearman: I'm not so sure. I think it is an internal VB interface as it seems to only happen with VB apps. I am curious as to its purpose, though I don't think it is a source of any errors. In fact, I should write a test for the Wine test suite and silence the fixme for that particular IID. wine archive
err:ole:CoGetClassObject class {62a1cafb-1940-798f-6859-a5623c7ba562} not registered
err:ole:CoGetClassObject no class object {62a1cafb-1940-798f-6859-a5623c7ba562}
could be created for for context 0x1
fixme:ole:CoCreateInstance no classfactory created for CLSID {62a1cafb-1940-798f-6859-a5623c7ba562},
hres is 0x80040154
err:ole:get_unmarshaler_from_stream Failed to create marshal, 0x80040154
err:ole:_unmarshal_interface Unmarshalling interface {b3b13603-a675-11d2-9b95-00104b71eb3f} failed with 80040154
R. Shearman [May 06]: Can you see what is under HKCR\Interface\{b3b13603-a675-11d2-9b95-00104b71eb3f}\ProxyStubClsid32 in your registry? He then posted another section of the trace where the bug was hiding..
trace:ole:_marshal_interface ...{b3b13603-a675-11d2-9b95-00104b71eb3f}...
trace:ole:CoMarshalInterface (0x798f1940, {b3b13603-a675-11d2-9b95-00104b71eb3f}, 0x79e309ec, 0, (nil),
MSHLFLAGS_NORMAL) trace:ole:IiFTMUnknown_fnQueryInterface
trace:ole:FTMarshalImpl_AddRef fixme:ole:FTMarshalImpl_GetUnmarshalClass (), stub!
Actually, this is the bug. This function doesn't fill in the CLSID properly. Also, UnmarshalInterface is unimplemented for the free-threaded marshaler. The free-threaded marshaler could really do with having some test-cases in the test suite. wine archive
wine debug then gives:
......
fixme:variant:VarBstrFromDec semi-stub
fixme:variant:VarBstrFromDec semi-stub
fixme:variant:VarBstrFromDec semi-stub
fixme:ole:MSFT_ReadValue BSTR length = -1?
fixme:ole:MSFT_ReadValue BSTR length = -1?
fixme:ole:ITypeLibComp_fnBind (L"CHR", 107e4b, 0x3, 0x4068ac60,
0x4068ac54, 0x4068ac6c): stub
fixme:ole:ITypeLibComp_fnBind (L"CHR", 107e4b, 0x3, 0x4068ac60,
0x4068ac54, 0x4068ac6c): stub
fixme:ole:ITypeLibComp_fnBind (L"CHR", 107e4b, 0x3, 0x4068ac60,
0x4068ac54, 0x4068ac6c): stub</pre>
R. Shearman: The function ITypeLibComp_fnBind is unimplemented. I've looked at this function before, but I haven't found enough documentation to implement it properly.Wine Archive Link
./../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so typelib.c && touch typelib.ok err:ole:TLB_ReadTypeLib Loading of typelib L"olepro32.dll" failed with error 1812 typelib.c:39: Test failed: Could not load type library fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:RegisterTypeLib Registering non-oleautomation interface!
S. Shemesh: Copying olepro32.dll from a windows solves this one. Wine Archive Link
Unregistered Dll
fixme:ole:CoCreateInstance no classfactory created for CLSID {a65b8071-3bfe-4213-9a5b-491da4461ca7}, hres is 0x80040154
^^^^^^^^^^
A. Mohr: why don't you regsvr32 that DLL (DxDiagProvider).[..] (darn, we need a *useful* error msg for that *frequent* error) [...] IMHO it should output something like:
- err:ole:CoGetClassObject class {a65b8071-3bfe-4213-9a5b-491da4461ca7}not registered
- - try running regsvr32 on the container DLL of this CLSID value!
which: - mentions regsvr32 - mentions that an unregistered DLL is involved And thus is an actually useful error message (to clueless endusers, that is).
R. Shearman: This is fixed by patch OLE #81a (Part 1) It will then output:
- err:ole:CoGetClassObject class {a65b8071-3bfe-4213-9a5b-491da4461ca7} not registered
If they have enough expertise to know that the CLSID is that of a DXDiag object then I think they will know that they can register it by using regsvr32 and I don't think this is the right place for documenting the possible reasons for the error. However, this particular problem was that the user didn't re-register all of the DLLs after upgrading. Maybe we should have something in the docs that tells the user to do this after upgrading to a new version of Wine or have it done automatically somehow.
[edit] Reading Com Port traces
000d:trace:comm:dump_dcb bytesize=8 baudrate=2400 fParity=0 Parity=0 stopbits=1
D. Riekenberg [May 2007 wine user] The App is using 2400 Baud here.
D. Moriarty: You can use setserial to set up comm 2 (or another box), link comm 1 to comm 2 (On 9 pin leads 2 - 3; 3 - 2; 5 - 5) will usually do it if you turn off hardware flow control, or get a 'laplink' lead. Make sure you have software flow control, and a parity bit. Then 'd d if=/dev/ttyS<integer> of=myfile bs=1 count=10000 will get you 10K of what it says.
=>1 0xb7d6934c memcpy+0x1c() in libc.so.6 (0x0033db78) 2 0x7bc53348 call_entry_point+0x20() in ntdll (0x0033db94) 3 0x7bc53d0c SNOOP_Return+0x9a4() in ntdll (0x0033dc04) 4 0x7e96d431 in oleaut32 (+0xd431) (0x7b8294bc) 5 0xfde80201 (0x02976854) 6 0x00000000 (0x00000000) 0xb7d6934c memcpy+0x1c in libc.so.6: repe movsl (%esi),%es%edi)
Vitamin [jul08] Snoop channel is unreliable and can cause crashes like that. So don't spend time trying to chase something that's not your problem.
wine client error:132: pipe: Too many open files wine client error:
Vitamin [wineuser aug 08] What does: ulimit -n say? Can you increase it and see what happens?
the user cautiously reported: It says 1024 Will check man page and try to increase whatever that is. [...] This experiment isn't currently being run on a work computer, it's being done on my personal laptop.
[edit] CLSID
You can list some of the Universal Unique Identifiers here, along with info that might help wine users. According to wikipedia CLSID is a class identifier; (Stored in the registry at HKEY_CLASSES_ROOT\CLSID)
Retrieving the COM class factory for component with CLSID {72C24DD5-D70A-438B-8A42-9842B88AFB8} - failed due to the following error: 800004002, at bt.a(String A_0, String A_1).
A English May 08 wine user, pointed to using winetricks to install a missing component
- sh winetricks wsh56
err:ole:CoGetClassObject class {00000507-0000-0010-8000-00aa006d2ea4} not registered err:ole:create_server class {00000507-0000-0010-8000-00aa006d2ea4} not registered
L. Lenders Jun 08 bug 13996: If you google for that uuid (or look in windows registry) you see it belongs to msado15.dll. Try http://kegel.com/wine/winetricks , winetricks art2kmin
Further Reading
[edit] Printing
fixme:commdlg:PRINTDLG_OpenDefaultPrinter Could not open printer EPSONStylusC42?! No such dialog is displayed
J.Lang: This is a red herring. It's not trying to display a dialog, it's telling you that the default printer specified in win.ini couldn't be opened. It's not a bug, but a configuration error.
fixme:commdlg:PRINTDLG_OpenDefaultPrinter Could not open printer styluscolor600?! err:psdrv:PSDRV_FindPrinterInfo OpenPrinterA failed with code 1801
Wineuser: Adding some entries in my wine registry (using regedit) and the win.ini in the fake_windows directory, like described in this tutorial: http://www.la-sorciere.de/Wine-HOWTO/wineprintconfig.html, in the part "Printing with the Internal Postscript Driver in Wine". Seems the tutorial isn't really up to date because I had to use [ppd] "generic" = "/usr/local/share/wine/generic.ppd" instead of [psdrv] ..., and I didn't need the entries for the afm-files.
Further Reading
fixme:psdrv:PSDRV_ExtEscape GETSETPRINTORIENT not implemented (data (nil))!
fixme:commdlg:PRINTDLG_SetUpPrinterListComboA Can't find 'tp0' in printer list so trying to find default
fixme:commdlg:PRINTDLG_SetUpPrinterListComboA Can't find default printer in printer list
fixme:commdlg:PRINTDLG_UpdatePrintDlgA No lpdm ptr?
fixme:commdlg:PRINTDLG_WMCommandA Update printdlg was not successful!
fixme:commdlg:PRINTDLG_UpdatePrintDlgA No lpdm ptr?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
fixme:commdlg:PRINTDLG_WMCommandA Update printdlg was not successful!
D. Riekenburg: [Sept05] DevMode - Support is incomplete in Wine yet. I'm working on this, but that will take a while (there a many unimplemented things in the Printing-Part of Wine). Wine Archive
[edit] XML
fixme:msxml:bsc_QueryInterface interface {6d5140c1-7436-11ce-8034-00aa006009fa} not implemented
fixme:msxml:bsc_QueryInterface interface {79eac9e4-baf9-11ce-8c82-00aa004ba90b} not implemented
Vitamin wineuser aug 08: Install msxml:[type in a terminal]
cd ~ w get http://www.kegel.com/wine/winetricks sh ./winetricks msxml3
msclrhd Nov 08 referring to a previous post: it cannot create an instance of the msxml4 object (that is what 88d969c1-f192-11d4-a65f-0040963251e5 is referring to). You can install this by running
- sh winetricks msxml4
[edit] Fonts
err:font:ReadFontDir Can't open directory "/usr/local/bin/../lib/../share/wine/fonts/"
A user noticed this error when when fontforge isn't installed.
D. Timoshkov: Missing fontforge means that you don't have Wine builtin fonts which leads to the above problems. The solution obviously is to install fontforge or use a binary Wine package instead.
The user noticed the path above.:It's relative to '/usr/local/bin', ok - but why the double descend into the parent directory? The "../lib" seems completely redundant with the "../share" coming right after it.
D. Timoshkov: That's a feature of a now fully relocatable Wine installation. wine archive
T. Spear clarified: What it does is check /usr/local/bin/wine/fonts and when it doesn't find the fonts there, it backs up and moves to /usr/local/lib/wine/fonts, when it doesn't find them there, it backs up again and moves to /usr/local/share/wine/fonts. When it doesn't find them there either, it fails.. That is why they say it is fully relocatable.. (AFAIK) You can move the entire install out of the bindir and wine won't die...
The user noted: [you tell about this] ERR about it at run-time. You do not tell in your error message what the ground cause for the ERR is.
M.McCormack: Some patches have been applied to Wine that should improve the situation. We now only warn at configure time.
trace:font:WineEngGetFontData font=0x405757d8, table=70616d63, offset=00000000, buf=0x4374720c, cbData=0 trace:font:WineEngGetFontData font=0x405757d8, table=20747663, offset=00000000, buf=0x4374859c, cbData=ffffec70
R. Klazes: cbData 0xffffec70looks wrong, it is supposed to be the length of buf (0x4374859c)[...] we get an fault accessing at an offset of 0xb0a64 of buf: First chance exception: page fault on write access to 0x437f9000 in 32-bit
The question is where this 0xffffec70 comes from. If you run with WINEDEBUG=+relay,+font can you spot this value anywhere? At least post 200 lines of this log directly preceding this line.
It turned out to be from a gdi call: R. Klazes: Here is an explanation [and a patch] The programs does:
- call GetFontData with buffer size zero, to return the required buffer size;
- do that for a number of font tables, adding the required sizes;;
- allocate a buffer large enough to store the data from all the GetFontData calls;
- then filling the buffer with GetFontData calls, using the return value of the call to calculate the remaining free size.
- because Wine's GetFontData is not returning the actual size of the data put in the buffer, but the buffer size it self. The pointer to the buffer data is now pointing beyond the boundary. It does not go wrong immediately because size is zero now, but at the following GetFontData call the page fault is inevitable. wine archive
trace:font:WineEngGetFontData font=7ff405d8, table=46454447,offset=00000000, buf=0, cbData=0 trace:font:WineEngGetFontData Can't find table 47444546.
A developer questioned [May 06]: Should freetype be able to find these these tables?
H.Davies: FreeType can load any TT table. Most likely the font in question doesn't contain these tables. wine archive
fixme:font:load_VDMX Failed to retrieve vTable
H. Davies: [Dec 05] It just means that the font doesn't have a VDMX table. The reason there's a fixme there is that I'm not sure whether we correctly scale the font in that case.
A. Mohr: This FIXME is quite confusing and should be fixed, since it's NOT at all about the "common" vTable term, but instead a VDMX font-related table AFAICS.
Use winedbg, set a breakpoint on load_VDMX(), step through it until the 2nd WineEngGetFontData() (that one is failing!), then step through it until you know what exactly fails. Maybe even a simple freetype upgrade might resolve the issue? (in that case we'd need to know which freetype version is problematic) wine archive
[edit] Networking
fixme:wininet:InternetGetConnectedState always returning LAN connection.
P. Troller: [Dec 05] Is your program requiring another kind of connection? [...] It's just a warning that a windoze app will not recognize whether the machine has a LAN, modem or whatever connection. It cannot influence a real connectivity. wine archive
[edit] Winsock
3757166 0009:Call ws2_32.gethostname(406dfadc,00000032) ret=004725e3 3757167 0009:trace:winsock:WS_gethostname name 0x406dfadc, len 50 3757168 0009:trace:winsock:WS_gethostname <- '[computername redacted].[domain name redacted]' 3757169 0009:Ret ws2_32.gethostname() retval=00000000 ret=004725e3 3757170 0009:Call ws2_32.gethostbyname(406dfadc "[computername redacted].[domain name redacted]") ret=004725f1 ... 3757177 0009:trace:winsock:WS_gethostbyname "[computername redacted].[domain name redacted]" ret (nil) 3757178 0009:Ret ws2_32.gethostbyname() retval=00000000 ret=004725f1 3757179 0009:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x4725f1 (some more exception lines)
M. Hearn: Yeah, a NULL return [ws2_32.gethostname() retval=00000000] means an error occurred. Most likely it's an invalid address, I get an NXDOMAIN for "[computername redacted].[domain name redacted]". Clearly Dreamweaver isn't expecting that call to fail as it doesn't bother checking the return result (assuming it's Dreamweaver that makes the call and not Wine itself). So the questions are:
1) Where does this name come from? 2) Why does it fail? 3) Why does Dreamweaver not expect that?
You need to do some more research I think. Try grepping the logs for that name and see where it appears first. BTW a +all trace is usually overkill, +relay is enough Wine Archive Link
A. Burrel: I wrote a small C program to find out the result of gethostbyname() and the result was h_errno=1 (HOST_NOT_FOUND). "[computername redacted]" is an internal address available only on our LAN, so it wouldn't work for you. "[computername redacted].[domain name redacted] [is] my computername and domain name... When I used "ping", I was able to contact the computer. However, by googling I determined that gethostbyname uses the $HOSTALIASES environment variable: mine was blank. so I added my own computername and IP to my /etc/hosts, and set $HOSTALIASES=/etc/hosts... Dreamweaver now starts for the first time since I installed it one year
M. McCormack: your distro should have done that. Not having your machine name aliased to 127.0.01/localhost in your /etc/hosts file is invalid and can cause all kinds of weird problems. I don't know what distro you're on but I'd recommend reporting the problem to them (or using a different distro)
Not All warns are a real error as this example showed:
trace:winsock:WSARecvFrom socket 00e8, wsabuf 0x33f638, nbufs 1, flags 0, from 0x33f67c, fromlen 16, ovl (nil), func (nil) trace:winsock:WSARecvFrom fd=51, options=0 warn:winsock:WSARecvFrom ->> ERROR 10035
any help on figuring out why the buffer is getting this error...
D. Jovanovic Aug 08 wine devel]: 10035 is WSAEWOULDBLOCK, which is normal for WSARecvFrom() on non-blocking sockets that currently have no data in the receive buffer. I'd be more worried if it wasn't [getting this warn]
[edit] MsgBox
A developer reported [May 06] that he tried: +msgbox to find a trace for the message box that's created, but that didn't seem to work for some reason.
M. Hearn: It might be generated by the app itself ... if you're sure it's a win32 message box look at the relay trace for MessageBox wine archive
[edit] HTML
$ wine iexplore fixme:shdocvw:IEWinMain "" 1 fixme:ole:CoResumeClassObjects stub Could not load Mozilla. HTML rendering will be disabled. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
J. Ernst [Jun 06]: I get the same thing even though I have mozilla installed. I'm using wine in 64-bit linux, though, so that probably has something to do with it. You don't need mozilla, but the Mozilla activex control : http://source.winehq.org/mozactivex I don't know why shdocvw doesn't prompt the user to install it in this case though (so I'm CCing wine-devel and Jacek to see if something has to be changed in nsembed.c). wine archive
[edit] Sound
[edit] Wave
[s2_at_katleriai Tetris]$ wine Tetris.exe err:wave:OSS_RawOpenDevice ioctl(/dev/dsp, SNDCTL_DSP_SETDUPLEX) failed (Input/output error)
R. Reif: Your sound card doesn't support full duplex which is required for DirectSound hardware acceleration.
dsound_test.exe.so dsound.c && touch dsound.ok err:wave:DSDB_MapBuffer Could not map sound device for direct access (Input/output error) err:wave:DSDB_MapBuffer Use: "HardwareAcceleration" = "Emulation" in the [dsound] section of your config file.
R. Rief: Seems to be a missing interface. I don't think the "Emulation" warning has anything to do with it, as some tests before it printed the same error, but passed. This is a bug in your OSS driver. It says it is capable of doing mmap but it fails when tried. The work around is to do as the message states: disable hardware acceleration (mmap).
fixme:wave:DSD_CreateSecondaryBuffer (0x454d16b8,0x4686cad8,ca,0,0x47a002ec,0x4041b054,0x47a002c8): stub
R. Rief:[Oct 05] This fixme is harmless. It just means your hardware supports hardware mixing but the wine OSS driver doesn't and falls back to software mixing. Wine Archive
A user tried some java software and reported:
swapper.jar: stack smashing attack in function WAVEMAP_widMessage() Aborted
M.Meissner: Very interesting and most likely informative message. You should check whether there is a function parameter count mismatch or function call type (cdecl, stdcall) mismatch around this area. That could easily explain this "stack smashing" error message. Actually it could also just be a bug in our wavemap code and we just might overflow the stack ourselves.Please [see which wavemap call triggers this] with wine archive
- WINEDEBUG=+wavemap,+mmsys wine javaw.exe -version
[edit] Midi
WINEDEBUG=+midi wine marbles.exe trace:midi:OSS_MidiInit Initializing the MIDI variables. ===>warn:midi:midiOpenSeq Can't open MIDI device '/dev/sequencer' ! (No ===>such device). If your program needs this (probably not): load MIDI ===>sequencer kernel driver !
la /dev/sequencer lrwxrwxrwx 1 ro ot root 15 sep 6 20:40 /dev/sequencer -> sound/sequencer
and the registry had:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\MCI32] "AVIVideo"="mciavi.drv" "CDAudio"="mcicda.drv" "Sequencer"="mciseq.drv" "WaveAudio"="mciwave.drv"
And as you see, it's available to everybody, so I have no idea why wine is reporting 'device not found'.
C. Costa[Sept 05]: What about /dev/sound/sequencer? Does it exist? mciseq.drv does not exist anymore, you should use mciseq.dll. You should also replace mciavi.drv and mcicda.drv by mciavi32.dll and mcicda.dll as well. Wine Archive
[edit] Dlls
Sometimes a dll is incomplete as one user found:
0009:Call usp10.ScriptItemize(7a2204f0 L" p\7a1c",00000002,000000ff,00000000,00000000,7b8ef018,7b8ef858) ret=0060c1f6 fixme:uniscribe:ScriptItemize L" p\7a1c",2,255,(nil),(nil),0x7b8ef018,0x7b8ef858 0009:Ret usp10.ScriptItemize() retval=80070057 ret=0060c1f6 0009:Call ntdll.RtlReAllocateHeap(7a1c0000,00000000,7a220688,2cd741b0) ret=006c4566
P. Beutner: [ Nov 05] The ScriptItemize() function is only implemented as stub atm, e.g. it does nothing, so i guess that somehow crashes your app. Try to use the native usp10.dll.
D. Clark provided some more info and pointed to where you can check what is implemented in the dll: the Wine version of usp10.dll is new as of 2005-07-27, so that may be why the program did not crash with earlier versions of Wine. [...] Before July, the Wine version of the dll did not exist. What applications sometimes do is test for the existance of a DLL, and if present, use functions in it. It would appear that may be what this app is doing. [...] Almost nothing is actually implemented in it, currently. http://source.winehq.org/source/dlls/usp10/usp10.c
Further Reading
[edit] Missing Dll
$ wine start Dreamweaver.exe L"C:\\Archivosde programa\\Macromedia\\DreamweaverMX\\Configuration\\JSExtensions\\DWEMLaunch.dll") not found
Alex: Dreamweaver still can't find the [...] even with the ["wine start exename.exe"] command, as demonstrated in the previous trace.
V. Margolen: You have to run it from other directory. Actually from _any_ directory but the one that exe is in. Don't ask me - ask m$ why they came up with this sort of .... stuff. Btw it will fail on win exactly the same way. [...]You need _literally_ run : wine start Dreamweaver.exe. And you can not be in the directory with that program. wine archive
err:module:import_dll Library Notifications.bpl (which is needed by L"C:\\Program Files\\UBC.new\\Adwiser2Main.bpl") not found
R. Klazes: If wine says "needed by xxxx" it means the xxxx file /is/ found, so there is only the case of odacvcl70.bpl, double check that file.
err:thunk:_loadthunk (NWMID95B.DLT, thunkobj_ThunkData16, NWMID95B.DLL): Unable to load 'NWMID95B.DLT', error 2
E.Pouch: wine dies because of this... it cannot find (or load) nwmid95b.dlt Wine Archive Linke
Does this mean the program cant find a dll?
> err:module:import_dll Library VCL30.dpl (which is needed by L"C:\\Program Files\\Mincom\\MIMS Open > Enterprise\\4.3\\bin\\msqexp.exe") not found
U. Bonnes: "dpl" or "dll" ?
Investigate deeper. Run e.g. with WINEDEBUG=+relay and look what happens when the application tries to find VCL30. WINEDEBUG=+relay,+file,+ntdll might give even more clues.Wine Archive
When installing I got the following errors:
fixme:richedit:RichEditANSIWndProc EM_AUTOURLDETECT: stub
fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub
fixme:richedit:RichEditANSIWndProc EM_LIMITTEXT: stub
fixme:richedit:RichEditANSIWndProc EM_EXLIMITTEXT: stub
fixme:richedit:ME_ReleaseStyle all style references freed (good!)
err:menubuilder:InvokeShellLinker failed to fork and exec wineshelllink
err:menubuilder:InvokeShellLinker failed to fork and exec wineshelllink
fixme:msvcrt:_setmbcp Unreal codepages (e.g. -3) not implemented
fixme:msvcrt:_setmbcp Unreal codepages (e.g. -3) not implemented
^^^^^^
A. Browaeys: I would say that using msvcrt from windows and telling wine to use it as native may help. Wine Archive Link
Further Reading
[edit] Dll Version Information
trace:ver:ConvertVersionInfo32To16 wLength 114, wValueLength 39, bText 64500, value 0x7baffbdc, child 0x7baffc2c trace:ver:ConvertVersionInfo32To16 Copied key from 0x7baffbd6 to 0x7baffb08: "?\x01" trace:ver:ConvertVersionInfo32To16 Copied value from 0x7baffbdc to 0x7baffb0c: "????????\x05" trace:ver:ConvertVersionInfo32To16 Converting 0x7baffc2c to 0x7baffb18 trace:ver:ConvertVersionInfo32To16 wLength 114, wValueLength 118, bText 105, value 0x7baffc48, child 0x7baffd34 trace:ver:ConvertVersionInfo32To16 Copied key from 0x7baffc32 to 0x7baffb1c: "ce Pack 2" trace:ver:ConvertVersionInfo32To16 Copied value from 0x7baffc48 to 0x7baffb28: "??\x01"
It looks like Translation Manager is doing a GetFileVersionInfoA with a fixed size of 512. It should have used GetFileVersionInfoSizeA probably first to get the size of the needed buffer. [According to ]MSDN: 'The VerQueryValue function retrieves specified version information from the specified version-information resource. To retrieve the appropriate resource, before you call VerQueryValue, you must first call the GetFileVersionInfoSize function, and then the GetFileVersionInfo function.'
The smaller than needed buffer leads us to the not-correct strings that show up in your trace. This means I have to change:
- 768 i f ( !VersionInfoIs16( info ) )
- 769 {
- 770 /* FIXME : The conversion is maybe a bit overkill, we only need 1 value */
- 771
- 772 ConvertVersionInfo32To16( (VS_VERSION_INFO_STRUCT32 *)info,
- 773 (VS_VERSION_INFO_STRUCT16 *)info );
- 774 }
in info.c [a patch was promised soon] Wine Archive
[edit] X Errors
err:xrandr:X11DRV_XRandR_GetCurrentMode In unknown mode, returning default fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 16 to 8 fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 16 to 8
I seem to remember that BPP cannot be changed _at all_ with XRandR, is this correct?
H. Verbeet: Yes.
If it is, then the obvious thing to do is to leave BPP alone and just change to the correct resolution. What needs fixing here?
J. Allen: You need to have 640x480 in your xorg.conf or XF86Config. If not that try capturing a log with * WINEDEBUG=+xrandr and see what is wrong.
trace:xrandr:X11DRV_XRandR_SetCurrentMode Changing Resolution to 640x480 @45961 Hz fixme:xrandr:X11DRV_XRandR_SetCurrentMode Cannot change screen BPP from 16 to 8 trace:xrandr:X11DRV_XRandR_SetCurrentMode Changing Resolution to 640x480 @45961 Hz fixme:x11drv:X11DRV_DDHAL_CreatePalette stub
It says "Changing Resolution to 640x480", so that sounds great - only it doesn't.
J. Allen: I'd maybe look through xorg.conf or you X.org log and see what is going on with those refresh frequencies. My xrandr works fine, so it might still be a setup issue.
I can switch to 640x480 just fine using [CTRL] [ALT] [-], does that mean that my xrandr is working? At least it means that my xorg.conf is fine, right. Nothing is written to Xorg.0.log when switching resolution manually or starting the game. Hmm.
N Skyrupch: That uses xvidmode to switch resolutions (and really just changes the amount you can view, the desktop size stays the same, try moving the mouse to the edges of the screen). xr andr is a different way of switching resolutions, which actually changes the resolution on the fly, try using 'krandrtr ay' or 'xran dr' to use xr andr instead. You should see the following in your Xorg.0.log file, if xrandr is enabled: (==) RandR enabled (II) Initializing built-in extension RANDR.
You can tell Wine to use xvidmode instead of xra ndr. Add UseXVidMode as Y and UseXRandR as N in \HKEY_CURRENT_USER\Software\Wine\X11 Driver.
J. Allen explained: If both XRandR and XVidMode are enabled, XRandR is preferred for mode setting. So all you need to do to make XVidMode take over is set UseXRandR = N, which obviously makes sense because XRandR is broken for him. wine archive
[edit] sfc
A user noted this error msg: fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program Files\\GeneXproTools 4\\SampleRuns\\XOR.gep") stub
D. Riekenberg: This indicates, that the Installer is correct. When an Installer does not give the fixme, it's outdated / incomplete. ":sfc:" is the dllname, and when you look at the only source-file, you will find: * Implementation of the System File Checker (Windows File Protection) wine archive
[edit] Drivers
wine: Call from 0x7b8458b0 to unimplemented function ntoskrnl.exe.IoQueryDeviceDescription, aborting
Aug 08 wineuser vitamin: This is [a] driver. Make sure you removed your ~/.wine directory before installing this program. It could be a left-over from some other program. If this driver [is] part of your program, then you out of luck.
Usurp: you can try to change Windows version in winecfg to Windows ME/9x.
[edit] SEH
err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0xb7942bd2 err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0xb7942bd2
D.Clark: try running wine like (assuming the bash shell):
WINEDEBUG=+relay wine battery & > wine.log
That will cause the program to run very slow, and can create a very large file (possibly 100s of MBytes) called wine.log. Search through the file for the first err:seh:EXC_DefaultHandling, and post a couple hundred lines prior to that to the Wine-Devel Mailing List. Wine Archive Link
trace:seh:__regs_RtlRaiseException code=c0000005
M Meissner [Jun 05]: "c0000005" is the Windows "Segmentation fault" code. [...]I need the 1000 lines _before_ those :seh: lines. wine archive
warn:seh:setup_exception exception outside of stack limits in thread 000c eip 7bed9651 esp 7f9510f4 stack 0x7f950000-0x7fa50000 err:seh:setup_exception nested exception on signal stack in thread 000c eip 7bed99fd esp 7ffffcd0 stack 0x7f950000-0x7fa50000
R. Shearman [July 05]: Looks like a crash inside an exception handler. Use the +seh debug channel or run in winedbg to see the source of the problem.
err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception.
S.Fievet: [oct 05] This error was with the game Warblade [...] According to Marcus it may be copy protection related. Wine Archive
000b:trace:seh:__regs_RtlRaiseException info[0]=deadcafe 000b:trace:seh:__regs_RtlRaiseException info[1]=deadcafe
A. Mohr [Oct 05]: deadcafe is another special magic value that might have been set by Wine code to indicate a problem. Wine Archive
[edit] Time and or Date
A. Woods encountered a crash in the Gecko Runtime Environment (GRE) part of the installer when trying to install Mozilla 1.7.7. If he changed winver from winxp to win95, he didn't get this problem.
typing bt with Winver as XP gave:
Backtrace:
=>1 0x557581df wine_cp_wcstombs(table=0x5584855c, flags=0x0, src=0x55c08a38, srclen=0x12, dst=0x99806858, dstlen=0x20, defchar=0x0,
used=0x0) [/var/tmp/portage/wine-cvs-1.1/work/wine/libs/unicode/wctomb.c:161] in libwine_unicode.so.1 (0x55c08934)
2 0x55a3a4f1 WideCharToMultiByte+0xe1(page=0x0, flags=0x0, src=0x55c08a38, srclen=0xffffffff, dst=0x99806858, dstlen=0x20,
defchar=0x0, used=0x0) [/var/tmp/portage/wine-cvs-1.1/work/wine/dlls/kernel/locale.c:1651] in kernel32 (0x55c08970)
3 0x60f61cfd PR_AttachThread+0x56a in nspr4 (0x55c08ae0)
He included a bit of the relay trace he and it includes the first occurance of that strange memory address (or anything near it for that matter). Since it's being passed into wine from Mozilla, I guess it is a problem within Mozilla.
WINEDEBUG +relay trace showed
0011:Call ntdll.RtlQueryTimeZoneInformation(55c08a34) ret=55a6fae5 0011:Ret ntdll.RtlQueryTimeZoneInformation() retval=00000000 ret=55a6fae5 0011:Call ntdll.NtQuerySystemTime(55c08874) ret=55a6ebc5 0011:Ret ntdll.NtQuerySystemTime() retval=00000000 ret=55a6ebc5 0011:Ret kernel32.GetTimeZoneInformation() retval=00000000 ret=60f61cd6 0011:Call kernel32.WideCharToMultiByte(00000000,00000000,55c08a38 L"GMT Standard Time",ffffffff,99806858,00000020,00000000,00000000) ret=60f61cfd
J. Lang: Mozilla's passing an apparently invalid pointer to WideCharToMultiByte... Running with WINEDEBUG=nls may give a clue what string it's trying to convert, which may give some indication of the problem. Running with WINEDEBUG=relay will probably give a better clue, but be prepared for a huge log. But since the Mozilla source is available, you may be able to hunt it down more easily using that.
J. Hawkins pointed out that it installs in Windows XP but not in xp mode in wine: Just because Mozilla is passing a bad memory address doesn't mean it's a bug in Mozilla. For example Mozilla could have requested some information from wine and we gave them the bad memory address. Then they call WideCharToMultiByte with the bad memory address we gave them. Your best bet is to find the first place this bad memory address pops up. Having a copy of the Mozilla source would probably be a good thing for this exercise.
J. Lang: While that's certainly possible in general, [that this is a Wine only bug, it] doesn't appear to be the case here. The bad pointer is the destination address of WideCharToMultiByte, not the source. Typically this will some buffer or other internal to Mozilla. I'm not claiming there isn't a bug in Wine. But I think the immediate thing we're seeing is a bug in Mozilla (likely triggered by a bug in Wine.) The nls trace might be interesting, because the source pointer appears to be valid. So, what string are they trying to translate? An error message perhaps? That might point to the cause of the problem.
A. Woods supplied a WINEDEBUG +relay,+nls log of what's happening just before the invalid memory address gets passed back.
J. Lang: Sweet, this turns up what we're looking for. (That doesn't mean I have a patch though.) We're back to it being a Wine bug, though Moz is doing something moderately questionable.
0011:Call kernel32.GetTimeZoneInformation(55c08a34) ret=60f61cd6
0011:Call ntdll.RtlQueryTimeZoneInformation(55c08a34) ret=55a6fae5
0011:Ret ntdll.RtlQueryTimeZoneInformation() retval=00000000 ret=55a6fae5
0011:Call ntdll.NtQuerySystemTime(55c08874) ret=55a6ebc5
0011:Ret ntdll.NtQuerySystemTime() retval=00000000 ret=55a6ebc5
0011:Ret kernel32.GetTimeZoneInformation() retval=00000000 ret=60f61cd6
0011:Call kernel32.WideCharToMultiByte(00000000,00000000,55c08a38 L"GMT Standard time",ffffffff,99806858,00000020,00000000,00000000)
ret=60f61cfd
I went over to lxr.mozilla.org/seamonkey and searched for GetTimeZoneInformation. That produced the following file: http://lxr.mozilla.org/seamonkey/source/nsprpub/pr/src/md/windows/ntmisc.c They're doing a WideCharToMultiByte into the global variable _tzname. As the comment says, perhaps they shouldn't be.. Anyway, _tzname should live in msvcrt, but our include/msvcrt/time.h has:
/* FIXME: Must do something for _daylight, _dstbias, _timezone, _tzname */
Mozilla is almost certainly wrong, though: the maximum size for the TZ environment variable is 15 chars (16 with the NULL): http://msdn.microsoft.com/library/en-us/vclib/html/_crt__tzset.asp .The corresponding names in _tzname are probably only 3 chars in length, so 4 bytes long including the NULL terminator.
A. Julliard: Actually, judging from the pointer values I get on my XP box the buffers seem to be 64 chars long (though I agree they will probably always contain at most 3 chars). Still, I'm not sure why Mozilla feels the need to overwrite them, that doesn't seem right.
J. Lang summarised: The crash was due to Mozilla attempting to write to a value that's exported by msvcrt.dll. It was declared in
msvcrt's spec file, but never defined. Thus Mozilla was writing to a garbage pointer. It's been fixed in Wine. There's a separate issue that Mozilla probably isn't doing the right thing. It's overwriting a buffer it doesn't own and whose size is not documented, and it should be writing only four characters but is writing more. Now that Wine is fixed this is unlikely to cause anyone any trouble, but it's still not right. [The discussion then turned to a patch for Mozilla] Wine Archive Link
[edit] Mouse
trace:dinput:SysMouseAImpl_SetCooperativeLevel (this=0x77c55f18,0x0008004c,0x00000006)
trace:dinput:SysMouseAImpl_SetCooperativeLevel cooperative level : DISCL_FOREGROUND DISCL_NONEXCLUSIVE
-----------^
L. Ulmer: This means that the mouse cursor will NOT be hidden by DInput. So S3 really uses the standard GDI cursor at the same time than DInput. Dossinger: I just noticed that S3 has a registry setting called "GDIMouse". This setting is reflected by the "use colored mouse pointer(if possible)" / "use monochrome mouse pointer" settings. ("Benutze farbigen Mauszeiger(wennm=F6glich)" and "Benutze monochrimen Mauszeiger" in my German version). Changing this Setting has no effect on S3 in Wine. I suppose S3 fails to draw its own mouse pointer in Wine and falls back to the GDI one.
[edit] USB
err:winedevice:ServiceMain driver L"DK12DRV" failed to load err:winedevice:ServiceMain driver L"hardlock" failed to load err:winedevice:ServiceMain driver L"Haspnt" failed to load
Vitamin Apr 08: Those are "USB dongle" drivers - they won't work on Wine. I'm assuming that they came with your program. If that's the case - it will not work on Wine as-is.
[edit] Twain
Doing WINEDEBUG=+loaddll wine finereader.exe
... trace:loaddll:load_dll Loaded module L"C:\\program files\\abbyy finereader 5.0 office\\scan\\scanman0.dll" : native trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\msvcrt.dll" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system\\msvcrt.dll" : builtin err:module:load_builtin_dll loaded .so for L"Twain.dll" but got L"twain_32.dll" instead - probably 16-bit dll trace:loaddll:MODULE_LoadModule16 Loaded module "c:\\windows\\Twain.dll" : builtin Scanning driver not ready.
S.Petreolle: "Builtin Scanning driver not ready" is suspicious. Has your linux scanner driver been loaded? Wine Archive Link
[edit] Memory
A programmer had been debugging why an n64 emulator ( Project64 ) gets "Failed to allocate memory" errors under wine 9.9.10 on linux kernel 2.6. [Mar 06] wine archive
The program allocates a large chunk of size 0x20100000, which succeeds, and then another large 0x10100000 chunk, which fails.
Wrote a test mmap binary to fill a process address space, it created a similar gap between the executable load address and the loaded shared libraries, eventually failing mmap calls when it hit the stack address space. When I updated the test app to explicitly mmap in the gap area via specifying the aligned start address, the mmap call succeeded. I can't be the first person to notice this. Are there any TODO solutions for this ?
One linux-centric solution would be to look for gaps like this in /proc/<pid>/maps in the libs/wine/mmap.c and take advantage of this. Or maybe another would be to keep a table of address spaces returned in wine_anon_mmap as a guide, then validate with try_mmap_fixed as to where a next-allocation should occur ( would this solution work outside linux )?
M McCormack: Wine's holey memory map has been discussed before:
The truely correct solution is probably to implement Windows compatible memory allocation in the Linux kernel, but there's other hacks that could be done in user space. Just a matter of finding something that Alexandre is willing to live with. A preload-ish type thing that overrode libc's mmap / munmap calls seems pausible to me.
[~/.wine/drive_c/Program Files/Warcraft III] wine war3.exe -opengl wine: Unhandled page fault on write access to 0x00495000 at address 0x495000 (thread 0009), starting debugger...
=>1 0x00495000 EntryPoint in war3 (0x00495000) 2 0xf7f763ab wine_switch_to_stack+0x17 in libwine.so.1 (0xf7f763ab) 0x00495000 EntryPoint in war3: pushl %eax
M. Meissner: Please run with:
- WINEDEBUG=+virtual wine war3.exe -opengl
And look for the virtual entries in the vicinity of 495000.
With the trace he added: Here is the culprit:
trace:virtual:VIRTUAL_SetProt 0x462000-0x4e7fff c-rW- trace:virtual:VIRTUAL_DumpView View: 0x400000 - 0x57bfff (anonymous) trace:virtual:VIRTUAL_DumpView 0x400000 - 0x400fff c-r-- trace:virtual:VIRTUAL_DumpView 0x401000 - 0x449fff c-r-x trace:virtual:VIRTUAL_DumpView 0x44a000 - 0x57bfff c-rW-
This covers the 0x00495000 address. Note that the area lacks the x-bit.
A patch was offered. wine archive
[edit] Stack
err:syslevel:_EnterSysLevel (0x40797840, level 2): Holding 0x4083ccc0, level 3. Expect deadlock! err:syslevel:_CheckNotSysLevel Holding lock 0x4083ccc0 level 3 err:seh:setup_exception stack overflow 176 bytes in thread 0009 eip 004078d5 esp 405b0f50 stack 0x405b0000-0x406b0000
O.Stieber:The stack overflow looks like somethings got stuck in a loop, which is problably why there were pages and pages of messages.
M. Hern: I think this happens when you hit Ctrl-C and the thread the exception is delivered to is holding the GDI/USER syslevel. The Ctrl-C handler provided by the runtime attempts to open a message box and fails to re-enter the lower syslevel which in turn triggers the CheckNotLock assertion. That then throws another exception and we go into an infinite loop.
In other words I think we can ignore this as it only happens when you press Ctrl-C, something common on Linux but very rare on Windows.
A. Woods while debugging WoW: I'm attaching to the process with gdb, but it's not catching things at the point where they go wrong. Typically I am just seeing a stack like this though:
#0 0x56752a01 in ?? ()
T. Rollo If it's only giving one frame in the stack trace the cause is normally a corrupted stack, so you may need to examine the stack to try to figure out where the stack frame should be (starting with "x/256xw" may be helpful if the stack pointer is still valid).
Otherwise, when debugging with GDB without going through winedbg you may need to use the "pass" command to skip over first chance exceptions in some cases before you get to the real exception.
A programmer noted [Oct 05]: The stackspace usage in dlls/ntdll/directory.c is affecting programs. One installer crashes because of it I suspect.
A. Julliard pointed out a possibility: Is it by any chance because it does a recursive search of the disk and runs out of stack? If that's the case you'll most likely see the overflow happen in one of the directory.c functions, but they are not the real culprit since they are not themselves recursive. Wine Archive
[edit] Heap
A programmer reported: The crash happens in the DDraw implementation. The return from Main_DirectDraw_Release(ddraw_main.c:154) leads to a random adress. The call which leads to this is "HeapFree(GetProcessHeap(), 0, This);" in Main_DirectDrawSurface_Destroy, surface_main.c:154. If I comment out this call, Empire Earth continues loading and crashes more or less randomly at some later points. I've edited the IDirectDrawSurfaceImpl structure and added a 2048 byte block at the beginning and the end. This makes the crashes reliable: With the HeapFree call, the ret jumps to NULL, and without the call Empire Earth crashes little later. BTW, Empire Earth crashes in exactly the same way in Cedega,
A second programmer replied: It probably has to do with some internal heap function, maybe some kind of buffer overrun somewhere. And since Cedega is basically a really old version of wine with a bunch of half-baked DX hacks in it, I would expect the crash to happen there as well.
The first programmer reported: This is interesting: Setting the +heap trace flag sets the bad address realiably to 0xaaaaaaaa(without my changes to DDraw). Does this say anything?
J. Ligget: Looks like an uninitialized value to me. I've seen similar cases like that, and that's what it was.
A. Mohr: dlls/ntdll/heap.c:#define ARENA_FREE_FILLER 0xaa
I'd guess this is an adress in an area that's actually gotten freed. Wine Archive
[edit] File Operations
First, kernel/file.c's CreateFileW is called > ------------- > trace:file:CreateFileW L"C:\\Program Files\\origin6.0\\UNTITLED.OPJ" > GENERIC_READ GENERIC_WRITE FILE_SHARE_READ FILE_SHARE_WRITE creation 5 > attributes 0x80 > ------------- > (creation 5 = TRUNCATE_EXISTING; attributes 0x80 = FILE_ATTRIBUTE_NORMAL) > > which then calls NtCreateFile: [...] > Which fails then with: > ------------- > warn:file:wine_nt_to_unix_file_name L"UNTITLED.OPJ" not found in /home/wine/.wine/dosdevices/c:/Program Files/origin6.0 > warn:ntdll:NtCreateFile L"\\??\\C:\\Program Files\\origin6.0\\UNTITLED.OPJ" not found (c0000034) > warn:file:CreateFileW Unable to create file L"C:\\Program Files\\origin6.0\\UNTITLED.OPJ" (status c0000034) > trace:file:CreateFileW returning 0xffffffff
A. Julliard: The problem is apparently that the app wants to create a new file using TRUNCATE_EXISTING, which fails if the file does not exist. So either the file should have been created earlier on, or the app is using the wrong creation argument for some reason.Wine Archive
warn:ntdll:NtCreateFile L"\\??\\C:" not found (c0000034) warn:file:CreateFileW Unable to create file L"\\\\.\\C:" (status c0000034)
D. Riekenburg: [L"\\??\\" is the] internal shortcut for "\\DosDevices". c0000034 is STATUS_OBJECT_NAME_NOT_FOUND. Wine is unable to find the simulated "C:\" - Drive. Delete your config and create a new one. Wine Archive
Get File Attributes
trace:file:GetFileAttributesW L"c:\\Program Files\\THQ\\Gas Powered Games\\Supreme Commander\\sounds\\Voice\\fr\\Tutorials\\TUB500.xwb" trace:file:RtlDosPathNameToNtPathName_U (L"c:\\Program Files\\THQ\\Gas Powered Games\\Supreme Commander\\sounds\\Voice\\fr\\Tutorials\\TUB500.xwb",0x334b84,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"c:\\Program Files\\THQ\\Gas Powered Games\\Supreme Commander\\sounds\\Voice\\fr\\Tutorials\\TUB500.xwb" 520 0x3348f8 (nil)) warn:file:wine_nt_to_unix_file_name L"TUB500.xwb" not found in /home/stephan/.wine/dosdevices/c:/Program Files/THQ/Gas Powered Games/SupremeCommander/sounds/Voice/fr/Tutorials
R. Shearman [Jun 07 wine devel]: These messages are normal. GetFileAttributes is often used by programs to check for the existence of a file.
Move File
trace:file:MoveFileWithProgressW (L"",(null),(nil),(nil),0004) trace:file:RtlDosPathNameToNtPathName_U (L"",0x3348b8,(nil),(nil))
R. Shearman [Jun 2007 wine devel]: This is not [normal]. Moving a file with a blank name isn't going to work properly. Probably a test case is needed to see what happens on Windows. However, my guess is that there is a bug elsewhere that causes the installer to not get the correct filename.
L"Territory",00000000,7c9bd738,7c9bd734,7c9bd730) ret=0081159d 000c:Call advapi32.RegQueryValueExW(00000138,008a440c L"Territory",00000000,7c9bd270,7c9bd26c,7c9bd268) ret=0081159d
L Rayhen [nov 07] RegQueryValueExW retrieves the type and data for the specified value name associated with an open registry key. So it *may* be a problem only if called during unusually slow file operations hundreds times per second and not during typical (fast) file operations. To be sure it is better to use profiling tools (see below for more information).
[note: do not run wine as root,as was done in this example - root does not help, and causes more problems]
warn:file:wine_nt_to_unix_file_name L"avicap32.dll" not found in /root/.wine/dosdevices/c:/windows/system32 warn:file:wine_nt_to_unix_file_name L"avicap32.dll" not found in /root/.wine/dosdevices/c:/windows warn:file:wine_nt_to_unix_file_name L"winealsa.drv" not found in /root/.wine/dosdevices/c:/windows/system32/drivers warn:file:wine_nt_to_unix_file_name L"winealsa.drv" not found in /root/.wine/dosdevices/c:/windows/system32/drivers
L. Rayhen [nov 07] Often WINE searches multiples paths to find particular library but if at least one search succeeds there is no error and you can ignore these warnings (you can use "grep -v" to filter them out).
"/root/.wine/dosdevices/c:/windows/system32/wsock32.dll" required a case-insensitive search
L. Rayhen [nov 07] This just means that "windows/system32/WSOCK32.dll" doesn't exist but "windows/system32/wsock32.dll" does. In Windows file system there is no difference but most Linux file systems are case-sensitive. So in such situation case-insensitive search required (this might be slow but can be a problem only if you search for hundreds or thousands of files per seconds).
[edit] Slow File Operations
L. Rayhen [nov 07] Because you want to find out what functions in WINE are slow, it is bad idea to just use debugging channels and try to find them manually. Most likely you just waste a lot of time and find nothing. What you want to do is to profile WINE not to debug it (in fact there is no bugs to debug in this case but some inefficiencies in the code). Therefore proper approach is to use profiling tools to find out what functions are slow in WINE. Read [1] for a brief introduction. Read [2] to find out how to use callgrind tool for profiling (see page 39, "Callgrind: a call graph profiler"); there is some other useful information in this document. You may want to install kcachegrind and read its help files - this is useful visual tool, you can use it with callgrind and OProfile. I really recommend you to read its help - it's short but helpful. Use Google to find more information.
- http://www.computer.org/portal/cms_docs_ieeecs/ieeecs/Communities/students/looking/2006Fall/02.pdf
- http://valgrind.org/docs/iiswc2006.pdf
[edit] Managing traces and clearing clutter
If your log is too big, you have trouble making anything of it and just want to cry help...
- R.Klazes: The interesting part is in the end (just control-c the program when the trouble is there). If the log is largely noise such as Enter/LeaveCriticalSection, EnterSysLevel, TlsGetvalue TlsSetValue, use grep to filter them out. Something like:
wine ... 2>&1 | egr ep -v 'CriticalSec|SysLevel|Tls.etVal' >wine.log
M. Hearn in dealing with a difficult logWine Archive thread Link: I'm afraid this trace reveals little also (not your fault though!). Try doing it again with the following in RelayExclude: _EnterSysLevel;_LeaveSysLevel;RtlEnterCriticalSection;RtlLeaveCriticalSection;GDI_GetObjPtr;GDI_ReleaseObj
Further Reading
