January 2014 - Wine-bugs - list.winehq.org

[Bug 35021] New: League of Legends installer page faults in custom action during stackwalk (SymFromAddr with NULL displacement ptr)
by wine-bugs＠winehq.org 10 Jan '14

10 Jan '14

http://bugs.winehq.org/show_bug.cgi?id=35021 Bug #: 35021 Summary: League of Legends installer page faults in custom action during stackwalk (SymFromAddr with NULL displacement ptr) Product: Wine Version: 1.7.7 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: dbghelp AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Classification: Unclassified Hello folks, I already mentioned this in bug 35011 ... not a big thing but it deserves it's own bug. The context capture/stack walk in custom action is done on purpose. --- snip --- 003b:trace:msi:ACTION_CallDllFunction calling L"OnAiRemoveFilesUndoable" ... 003b:Call dbghelp.SymGetModuleBase(ffffffff,7d4fd3f7) ret=7e458574 003b:Ret dbghelp.SymGetModuleBase() retval=7d4d0000 ret=7e458574 003b:Call dbghelp.SymFunctionTableAccess(ffffffff,7d4fd3f7) ret=7e458515 003b:Ret dbghelp.SymFunctionTableAccess() retval=00000000 ret=7e458515 003b:Ret dbghelp.StackWalk() retval=00000001 ret=003b337f 003b:Call ntdll.RtlAllocateHeap(00bb0000,00000000,00000020) ret=003c8570 003b:Ret ntdll.RtlAllocateHeap() retval=00bb41d0 ret=003c8570 003b:Call dbghelp.SymFromAddr(ffffffff,7d4fd3f7,00000000,00000000,00bb39a0) ret=003b3844 003b:Call ntdll.RtlReAllocateHeap(00110000,00000000,01300030,0000ad88) ret=7e45be05 003b:Ret ntdll.RtlReAllocateHeap() retval=01300030 ret=7e45be05 003b:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7e45d158 ip=7e45d158 tid=003b 003b:trace:seh:raise_exception info[0]=00000001 003b:trace:seh:raise_exception info[1]=00000000 003b:trace:seh:raise_exception eax=0000000b ebx=00000000 ecx=00000000 edx=00000000 esi=7d4fd3ec edi=00000000 003b:trace:seh:raise_exception ebp=00ebca58 esp=00ebca20 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00210246 003b:trace:seh:call_stack_handlers calling handler at 0x3d840d code=c0000005 flags=0 ... 003b:trace:seh:__regs_RtlUnwind handler at 0x3da946 returned 1 003b:trace:seh:__regs_RtlUnwind calling handler at 0x3cb818 code=c0000005 flags=2 003b:trace:seh:__regs_RtlUnwind handler at 0x3cb818 returned 1 003b:trace:seh:__regs_RtlUnwind calling handler at 0x7bc81a26 code=c0000005 flags=2 003b:trace:seh:__regs_RtlUnwind handler at 0x7bc81a26 returned 3 003b:Ret ntdll.RtlUnwind() retval=00000000 ret=7d566735 003b: eax=00000000 ebx=7d5c7000 ecx=00eba318 edx=00eba318 esi=00ebe8d0 edi=7d56674a ebp=00eb9e08 esp=00eb9dd8 ds=002b es=002b fs=0063 gs=006b flags=00200216 003b:err:msi:ACTION_CallDllFunction Custom action (L"C:\\users\\focht\\Temp\\msi5823.tmp":L"OnAiRemoveFilesUndoable") caused a page fault: c0000005 003b:trace:msi:MsiCloseHandle 6 003b:trace:msi:MsiCloseHandle handle 6 destroyed 003b:Call KERNEL32.FreeLibrary(00390000) ret=7d4fd812 003b:Ret KERNEL32.FreeLibrary() retval=00000001 ret=7d4fd812 003b:trace:msi:MsiCloseHandle 5 003b:trace:msi:MsiCloseHandle handle 5 destroyed 003b:Call ntdll.RtlFreeHeap(00110000,00000000,00914c28) ret=7d532a5a 003b:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7d532a5a 003b:Call oleaut32.SysFreeString(00914e24 L"C:\\users\\focht\\Temp\\msi5823.tmp") ret=7d4fd83c 003b:Ret oleaut32.SysFreeString() retval=00000000 ret=7d4fd83c 003b:Call oleaut32.SysFreeString(0090404c L"OnAiRemoveFilesUndoable") ret=7d4fd84a 003b:Ret oleaut32.SysFreeString() retval=00000000 ret=7d4fd84a 003b:trace:msi:MsiCloseHandle 5 003b:trace:msi:DllThread custom action (3b) returned 0 003b:trace:msi:MsiCloseAllHandles --- snip --- Wine unconditionally writes to the optional out parameter 'Displacement' in SymFromAddr() for which the caller passes NULL, causing a page fault. MSDN says: http://msdn.microsoft.com/en-us/library/windows/desktop/ms681323%28v=vs.85%… --- quote --- Displacement [out, optional] The displacement from the beginning of the symbol, or zero. --- quote --- Source: http://source.winehq.org/git/wine.git/blob/836b682ed3bff439f1264bc9cee4ecce… (fault caused in line 1232) --- snip --- 1219 BOOL WINAPI SymFromAddr(HANDLE hProcess, DWORD64 Address, 1220 DWORD64* Displacement, PSYMBOL_INFO Symbol) 1221 { 1222 struct module_pair pair; 1223 struct symt_ht* sym; 1224 1225 pair.pcs = process_find_by_handle(hProcess); 1226 if (!pair.pcs) return FALSE; 1227 pair.requested = module_find_by_addr(pair.pcs, Address, DMT_UNKNOWN); 1228 if (!module_get_debug(&pair)) return FALSE; 1229 if ((sym = symt_find_nearest(pair.effective, Address)) == NULL) return FALSE; 1230 1231 symt_fill_sym_info(&pair, NULL, &sym->symt, Symbol); 1232 *Displacement = Address - Symbol->Address; 1233 return TRUE; 1234 } --- snip --- Regards -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 5

[Bug 34811] New: Crash when copy by ctrl+c or in-app copy, cmd+c works fine (using MacDriver) on OS X Mavericks
by wine-bugs＠winehq.org 10 Jan '14

10 Jan '14

http://bugs.winehq.org/show_bug.cgi?id=34811 Bug #: 34811 Summary: Crash when copy by ctrl+c or in-app copy, cmd+c works fine (using MacDriver) on OS X Mavericks Product: Wine Version: 1.7.5 Platform: x86-64 OS/Version: Mac OS X Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: mememe12(a)me.com Classification: Unclassified Created attachment 46420 --> http://bugs.winehq.org/attachment.cgi?id=46420 Error in console after using ctrl+c When I copy text (ctrl+c) in Keil uVision 4 in wine using MacDriver on OS X Mavericks , it crashes leaving this error in log (see attachment). When I use cmd+c to copy, it's fine, but I have to be aware (cmd + c & ctrl+ v to copy& paste). It won't crash when I use XQuartz instead of MacDriver. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 11

[Bug 30745] New: Soulbringer, GOG version, crashes at start, no splash screen even.
by wine-bugs＠winehq.org 10 Jan '14

10 Jan '14

http://bugs.winehq.org/show_bug.cgi?id=30745 Bug #: 30745 Summary: Soulbringer, GOG version, crashes at start, no splash screen even. Product: Wine Version: 1.5.4 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: fernando(a)cmartins.nl Classification: Unclassified see backtrace -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 19

[Bug 15738] New: Max Payne 2: Ingame windows rendered incorrect with nvts pipe
by wine-bugs＠winehq.org 10 Jan '14

10 Jan '14

http://bugs.winehq.org/show_bug.cgi?id=15738 Summary: Max Payne 2: Ingame windows rendered incorrect with nvts pipe Product: Wine Version: 1.1.3 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: directx-d3d AssignedTo: wine-bugs(a)winehq.org ReportedBy: liquid.acid(a)gmx.net When using (or forcing) the nvts_fragment_pipeline implementation (directx.c), ingame windows are rendered incorrectly. Going to attach screenshots later. With the arbfp pipe rendering is correct, I didn't yet try with other pipes. Effect can be reproduced with the demo version. Start game and let cutscenes finish (wait until you gain control of the character), then take a look at the windows in the hospital room. With nvts they're completly transparent, nearly like they weren't even there. Recheck with arbfp and see how they should look like (you should see a "sprinkled-by-rain-from-outside" effect on them). Exit first room and look left for another window. It has the same issues, however I found out that it was possible to trigger correct rendering when the scene is rendered from a certain position (again going to do screenshots). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 26

[Bug 33799] New: Wargame: Airland Battle crashes because of unimplemented function
by wine-bugs＠winehq.org 10 Jan '14

10 Jan '14

http://bugs.winehq.org/show_bug.cgi?id=33799 Bug #: 33799 Summary: Wargame: Airland Battle crashes because of unimplemented function Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt AssignedTo: wine-bugs(a)winehq.org ReportedBy: yurishish(a)gmail.com Classification: Unclassified After launching game crashes immediately and appears Unhandled exception message -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 8

[Bug 34813] New: winedbg crash reports are missing important information on Mac OS X 10.8+
by wine-bugs＠winehq.org 10 Jan '14

10 Jan '14

http://bugs.winehq.org/show_bug.cgi?id=34813 Bug #: 34813 Summary: winedbg crash reports are missing important information on Mac OS X 10.8+ Product: Wine Version: unspecified Platform: x86 OS/Version: Mac OS X Status: NEW Severity: normal Priority: P2 Component: dbghelp AssignedTo: wine-bugs(a)winehq.org ReportedBy: ken(a)codeweavers.com Classification: Unclassified For an example, see attachment 46421 from bug 34811. Built-in DLLs are shown as PE modules instead of ELF wrappers around PE modules. The address ranges for the modules are likely incorrect. Many of them are shown as taking 4 pages (16KB) when I'm sure they're much larger. For example, gdi32. As a consequence, none of the stack frames resolve to symbols/functions. Few of them even resolve to modules other than "<wine-loader>". I believe this only affects OS X 10.8 and later. It doesn't affect 10.6.8. I suspect it has to do with image sliding. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 7

[Bug 18465] New: url.dll FileProtocolHandler does not open URLs in browser.
by wine-bugs＠winehq.org 10 Jan '14

10 Jan '14

http://bugs.winehq.org/show_bug.cgi?id=18465 Summary: url.dll FileProtocolHandler does not open URLs in browser. Product: Wine Version: 1.0.1 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: kempe.marcus(a)gmail.com The following call: wine rundll32 url.dll,FileProtocolHandler http://www.winehq.org/ does not open the wine homepage in my default browser, as is done in Windows. However, if i add the following 2 dlls from windows: url.dll iertutil.dll to my wine-installation, the the call works as expected. This leads me to believe that there might be a bug, or simply an unimplemented feature. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

1 16

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org 10 Jan '14

10 Jan '14

https://bugs.winehq.org/show_bug.cgi?id=2082 --- Comment #139 from Henri Verbeet <hverbeet(a)gmail.com> --- (In reply to comment #138) > (In reply to comment #136) > > > - The main thing I'm wondering about is if it wouldn't make more sense to > > pass a window to wglCreateFullscreenDCWINE(). Some of the considerations > > there are what should happen when the device window is e.g. destroyed or > > minimized. > > It seems like knowing how to respond to such events should be the > responsibility of ddraw/d3d. The driver can provide the tools necessary for > those to implement the proper behavior. If we know what those are, we can > add them to the extension. > It's mostly that I have the impression that at least in d3d8 and d3d9 the way it conceptually works is that D3D draws to a DC retrieved by GetWindowDC() on the device window. I don't really have tests to back that up though, and even then ddraw could very well be different. > > - When there are multiple threads drawing, wglCreateFullscreenDCWINE() is > > going to be called multiple times for the same window / display. I didn't > > really review the winemac.drv changes, but will it do the right thing in > > that case? > > Good question. > > The implementation in the patch creates a single Cocoa window for all > full-screen DCs. So the rendering from all contexts would go to the same > drawable. Currently, there's also a single pixel format tracked, although > it always allows the pixel format to be changed even if it was already set. > That's almost certainly wrong. I was planning to change that to track the > pixel format per DC in which case I'd probably enforce the usual rules about > changing it. I'm not sure that's right, either. Does it make sense for > multiple callers to create separate DCs with separate pixel formats but > sharing a drawable? > The pixel format should always be the same between threads / contexts belonging to the same swapchain. The main variable that has an influence on the pixel format is the swapchain's backbuffer format. > Here's another approach to that same question. What if the > WGL_WINE_fullscreen_dc extension didn't add any new functions? What if it > simply indicated that doing OpenGL on the screen DC returned by GetDC(0) was > allowed and full-featured? Then, the change to wined3d would be to simply > use GetDC(0) for a full-screen swapchain. Releasing the DC could go through > ReleaseDC() (and maybe wined3d_release_dc() with some tweaking). > Looking at the MSDN for GetWindowDC(), we'd probably want that to either be CreateDC() for the appropriate driver, or GetWindowDC() on the device window. I do think we'd want some way for the caller to have to explicitly request this behaviour, perhaps through a custom MakeCurrent() as proposed earlier. > Would that work? What about the issue with the pixel format? Are there > other issues? A somewhat related issue is that for applications using OpenGL, the DC is visible through wglGetCurrentDC(). I don't know if that will necessarily break anything, but I wouldn't be terribly surprised if it did. (See also e.g. bug 29934 and bug 28869.) Ideally the wined3d GL context, pixel format, etc. would be completely invisible to the application, but that would probably require some equivalent of context_enter() / context_release() in winex11 / winemac. Also slightly related to this bug are bug 29301 and bug 30062. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8539] VMXBuider 0.8 (VB6 app) fails to create new VM, reporting "Run-time error '-2147417848 (80010108)': Automation error"
by wine-bugs＠winehq.org 10 Jan '14

10 Jan '14

http://bugs.winehq.org/show_bug.cgi?id=8539 --- Comment #19 from Nikolay Sivov <bunglehead(a)gmail.com> --- I don't trust IRecordInfo to be honest, mostly because it doesn't have any tests. I'll try to find time this weekend to improve the situation. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8539] VMXBuider 0.8 (VB6 app) fails to create new VM, reporting "Run-time error '-2147417848 (80010108)': Automation error"
by wine-bugs＠winehq.org 09 Jan '14

09 Jan '14

http://bugs.winehq.org/show_bug.cgi?id=8539 --- Comment #18 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, commit http://source.winehq.org/git/wine.git/commitdiff/b058c96136850e543d171d766e… from bug 23005 helped a bit, the pre-checks of 'psa->fFeatures' on __vbaAryRecCopy() entry are now passed. Still crashes though. --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/RDPSoftware/VMware/VMX Builder $ WINEDEBUG=+tid,+seh,+relay,+snoop,+ole,+variant wine ./VMXBuilder.exe >>log.txt 2>&1 ... 0028:Call oleaut32.SafeArrayAllocData(01ba6c98) ret=660db9e8 0028:trace:variant:SafeArrayAllocData (0x1ba6c98) 0028:Call ntdll.RtlAllocateHeap(00110000,00000008,000001a0) ret=7e7b19ac 0028:Ret ntdll.RtlAllocateHeap() retval=01ba6e58 ret=7e7b19ac 0028:trace:variant:SafeArrayAllocData 416 bytes allocated for data at 0x1ba6e58 (52 objects). 0028:Ret oleaut32.SafeArrayAllocData() retval=00000000 ret=660db9e8 0028:Call oleaut32.SafeArraySetRecordInfo(01ba6c98,01ba5668) ret=660dba31 0028:trace:variant:SafeArraySetRecordInfo (0x1ba6c98,0x1ba5668) ... 0028:Call oleaut32.SafeArrayCopy(01ba6d04,01ba6c90) ret=66103c0e 0028:trace:variant:SafeArrayCopy (0x1ba6d04,0x1ba6c90) 0028:trace:variant:SafeArrayGetVartype (0x1ba6d04,0x33e102) 0028:trace:variant:SafeArrayAllocDescriptorEx (36->VT_RECORD,2,0x1ba6c90) 0028:trace:variant:SafeArrayAllocDescriptor (2,0x1ba6c90) 0028:Call ntdll.RtlAllocateHeap(00110000,00000008,00000030) ret=7e7b19ac 0028:Ret ntdll.RtlAllocateHeap() retval=01bc5b90 ret=7e7b19ac 0028:trace:variant:SafeArrayAllocDescriptor (2): 32 bytes allocated for descriptor. 0028:Call ntdll.RtlAllocateHeap(00110000,00000008,000001a0) ret=7e7b19ac 0028:Ret ntdll.RtlAllocateHeap() retval=01bc5bc8 ret=7e7b19ac 0028:trace:variant:SafeArrayGetRecordInfo (0x1ba6d04,0x33e0a4) 0028:trace:ole:IRecordInfoImpl_AddRef (0x1ba5668) -> 14 0028:trace:variant:SafeArraySetRecordInfo (0x1bc5ba0,0x1ba5668) 0028:trace:ole:IRecordInfoImpl_AddRef (0x1ba5668) -> 15 0028:trace:ole:IRecordInfoImpl_Release (0x1ba5668) -> 14 0028:Ret oleaut32.SafeArrayCopy() retval=00000000 ret=66103c0e 0028:RET MSVBVM60.__vbaAryRecCopy(4872ce2c,01ba6c90,0033e1ac) retval=00000000 ret=48754a9c 0028:CALL MSVBVM60.__vbaAryRecCopy(4872ce2c,01ba6c90,0033e1ac) ret=48754a9c 0028:Call oleaut32.SafeArrayDestroyData(01bc5ba0) ret=660db598 0028:trace:variant:SafeArrayDestroyData (0x1bc5ba0) 0028:trace:variant:SafeArrayGetRecordInfo (0x1bc5ba0,0x33e0b8) 0028:trace:ole:IRecordInfoImpl_AddRef (0x1ba5668) -> 15 0028:trace:ole:IRecordInfoImpl_RecordClear (0x1ba5668)->(0x1bc5bc8) 0028:trace:ole:IRecordInfoImpl_RecordClear (0x1ba5668)->(0x1bc5be8) 0028:trace:ole:IRecordInfoImpl_RecordClear (0x1ba5668)->(0x1bc5c08) 0028:Call ntdll.RtlFreeHeap(00110000,00000000,01bab4f0) ret=7e7a03d6 0028:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7e7a03d6 0028:trace:ole:IRecordInfoImpl_RecordClear (0x1ba5668)->(0x1bc5c28) 0028:Call ntdll.RtlFreeHeap(00110000,00000000,01bab530) ret=7e7a03d6 0028:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7e7a03d6 ... 0028:trace:ole:IRecordInfoImpl_RecordClear (0x1ba5668)->(0x1bc5d48) 0028:Call ntdll.RtlFreeHeap(00110000,00000000,01bab838) ret=7e7a03d6 0028:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7e7a03d6 0028:Call ntdll.RtlFreeHeap(00110000,00000000,01bab870) ret=7e7a03d6 0028:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7e7a03d6 0028:trace:ole:IRecordInfoImpl_RecordClear (0x1ba5668)->(0x1bc5d68) 0028:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7e7a01e5 ip=7e7a01e5 tid=0028 0028:trace:seh:raise_exception info[0]=00000000 0028:trace:seh:raise_exception info[1]=00002935 0028:trace:seh:raise_exception eax=00002935 ebx=7e8aa000 ecx=0033e010 edx=00000000 esi=0033e090 edi=7e7aff38 0028:trace:seh:raise_exception ebp=0033dff8 esp=0033dfc0 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00210206 0028:trace:seh:call_stack_handlers calling handler at 0x48723286 code=c0000005 flags=0 0028:CALL MSVBVM60.__vbaExceptHandler(<unknown, check return>) ret=7bc866c9 --- snip --- Release of old resources before copy new data: __vbaAryRecCopy() -> __vbaErase() -> SafeArrayDestroyData() on target safearray Seems some double free of bstr. --- snip --- Wine-dbg>bt Backtrace: =>0 0x7e7a01e2 SysFreeString+0x36(str=<couldn't compute location>) [/home/focht/projects/wine/wine-git/dlls/oleaut32/oleaut.c:259] in oleaut32 (0x0033e078) 1 0x7e7aff45 IRecordInfoImpl_RecordClear+0x1f8(iface=<couldn't compute location>, pvExisting=<couldn't compute location>) [/home/focht/projects/wine/wine-git/dlls/oleaut32/recinfo.c:219] in oleaut32 (0x0033e0f8) 2 0x7e7b2059 SAFEARRAY_DestroyData+0x16b(psa=0x1b53038, ulStartCell=0) [/home/focht/projects/wine/wine-build32/dlls/oleaut32/../../include/oaidl.h:4150] in oleaut32 (0x0033e178) 3 0x7e7b3d4a SafeArrayDestroyData+0x9f(psa=0x1b53038) [/home/focht/projects/wine/wine-git/dlls/oleaut32/safearray.c:1239] in oleaut32 (0x0033e1c0) 4 0x660db598 in msvbvm60 (+0xdb597) (0x0033e1f4) 5 0x48754a9c in vmcomps (+0x34a9b) (0x0033e238) 6 0x004b5b1a in vmxbuilder (+0xb5b19) (0x0033e2d4) 7 0x0047650f in vmxbuilder (+0x7650e) (0x0033e37c) 8 0x660ca914 in msvbvm60 (+0xca913) (0x0033e3d8) Wine-dbg>p *This {IRecordInfo_iface={lpVtbl=0x7e8c0700}, ref=0xf, guid={Data1=0x97dfd25d, Data2=0x596c, Data3=0x4f93, Data4="????"}, lib_index=0, n_vars=0x2, size=0x8, name="GuestOSVer", fields=0x1b32a78, pTypeInfo=0x1b32888} ... {vt=VT_BSTR, varkind=VAR_PERINSTANCE, offset=0, name="DisplayedName"} {vt=VT_BSTR, varkind=VAR_PERINSTANCE, offset=0x4, name="ConfigName"} --- snip --- Disabling bstr caching with OANOCACHE=1 didn't change behaviour (point of crash didn't move). Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0