https://bugs.winehq.org/show_bug.cgi?id=40419
Bug ID: 40419
Summary: Blade and Soul installer crashes
Product: Wine-staging
Version: 1.9.7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: linuxdonald(a)posteo.de
CC: erich.e.hoover(a)wine-staging.com, michael(a)fds-team.de,
sebastian(a)fds-team.de
Distribution: ---
The installer crashes with:
wine: Call from 0x7b43cd3c to unimplemented function
sfc.dll.SRSetRestorePointW, aborting
wine: Unimplemented function sfc.dll.SRSetRestorePointW called at address
0x7b43cd3c (thread 0009), starting debugger...
--
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.
https://bugs.winehq.org/show_bug.cgi?id=40452
Bug ID: 40452
Summary: Devil May Cry 4 Benchmark instillation fails
Product: Wine
Version: 1.9.7
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: levanchelidze(a)gmail.com
Distribution: ---
Created attachment 54201
--> https://bugs.winehq.org/attachment.cgi?id=54201
becktrace
I tried to install dmc 4 benchmark on a clean prefix and the installation
crashed
--
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.
https://bugs.winehq.org/show_bug.cgi?id=40521
Bug ID: 40521
Summary: Max Payne 3 Installation wants
sfc.dll.SRSetRestorePointW function
Product: Wine
Version: 1.9.8
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: berillions(a)gmail.com
Distribution: ---
Hi,
At the beginning and at the end of Max Payne 3 installation, i have this error
message in the output console :
wine: Call from 0x7b43bc8c to unimplemented function sfc.dll.SRSetRestorePointW
At the end, Wine crash when the installer wants to install DirectX libraries.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=39452
Bug ID: 39452
Summary: WNetGetUniversalName() returns ERROR_NO_NETWORK
(0x000004c6)
Product: Wine
Version: 1.7.52
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: alexey.pushkin(a)mererand.com
Distribution: ---
WNetGetUniversalName() is a stub function and it returns ERROR_NO_NETWORK
(0x000004c6).
I believe it should instead return ERROR_NOT_CONNECTED, which would mean that
Wine treats the path argument as a _local_ path.
See
https://msdn.microsoft.com/en-us/library/windows/desktop/aa385474%28v=vs.85…
According to WINEDEBUG=relay Intel MPI
(https://software.intel.com/en-us/intel-mpi-library) pmi_proxy.exe exits after
receiving ERROR_NOT_CONNECTED from WNetGetUniversalName().
--
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.
https://bugs.winehq.org/show_bug.cgi?id=43383
Bug ID: 43383
Summary: valgrind shows several definite leak in
dlls/qcap/tests/smartteefilter.c
Product: Wine
Version: 2.12
Hardware: x86
OS: Linux
Status: NEW
Keywords: download, source, testcase, valgrind
Severity: normal
Priority: P2
Component: qcap
Assignee: wine-bugs(a)winehq.org
Reporter: austinenglish(a)gmail.com
Distribution: Gentoo
==31520== 72 bytes in 1 blocks are definitely lost in loss record 321 of 616
==31520== at 0x7BC51061: notify_alloc (heap.c:254)
==31520== by 0x7BC5554F: RtlAllocateHeap (heap.c:1716)
==31520== by 0x4F1442B: IMalloc_fnAlloc (ifs.c:187)
==31520== by 0x4F14CCB: IMalloc_Alloc (objidl.h:1405)
==31520== by 0x4F14CCB: CoTaskMemAlloc (???:0)
==31520== by 0x606C8DA: ???
==31520== by 0x4A21688: IMediaSample_SetMediaType (strmif.h:2289)
==31520== by 0x4A21688: media_thread (???:0)
==31520== by 0x7BC913B3: ??? (signal_i386.c:2700)
==31520== by 0x7BC9143B: call_thread_func (signal_i386.c:2759)
==31520== by 0x7BC91391: ??? (signal_i386.c:2700)
==31520== by 0x7BC9B3EE: start_thread (thread.c:487)
==31520== by 0x4244249: start_thread (pthread_create.c:333)
==31520== by 0x433FD6D: clone (clone.S:114)
==31520==
==31520== 72 bytes in 1 blocks are definitely lost in loss record 322 of 616
==31520== at 0x7BC51061: notify_alloc (heap.c:254)
==31520== by 0x7BC5554F: RtlAllocateHeap (heap.c:1716)
==31520== by 0x4F1442B: IMalloc_fnAlloc (ifs.c:187)
==31520== by 0x4F14CCB: IMalloc_Alloc (objidl.h:1405)
==31520== by 0x4F14CCB: CoTaskMemAlloc (???:0)
==31520== by 0x606C8DA: ???
==31520== by 0x5FF3D18: ???
==31520== by 0x5FF3F76: ???
==31520== by 0x60006CA: ???
==31520== by 0x4A21771: IMemInputPin_Receive (strmif.h:3041)
==31520== by 0x4A21771: media_thread (???:0)
==31520== by 0x7BC913B3: ??? (signal_i386.c:2700)
==31520== by 0x7BC9143B: call_thread_func (signal_i386.c:2759)
==31520== by 0x7BC91391: ??? (signal_i386.c:2700)
==31520== by 0x7BC9B3EE: start_thread (thread.c:487)
==31520== by 0x4244249: start_thread (pthread_create.c:333)
==31520== by 0x433FD6D: clone (clone.S:114)
==31520==
==31520== 72 bytes in 1 blocks are definitely lost in loss record 324 of 616
==31520== at 0x7BC51061: notify_alloc (heap.c:254)
==31520== by 0x7BC5554F: RtlAllocateHeap (heap.c:1716)
==31520== by 0x4F1442B: IMalloc_fnAlloc (ifs.c:187)
==31520== by 0x4F14CCB: IMalloc_Alloc (objidl.h:1405)
==31520== by 0x4F14CCB: CoTaskMemAlloc (???:0)
==31520== by 0x606C8DA: ???
==31520== by 0x5FF3D18: ???
==31520== by 0x5FF4014: ???
==31520== by 0x60006CA: ???
==31520== by 0x4A21771: IMemInputPin_Receive (strmif.h:3041)
==31520== by 0x4A21771: media_thread (???:0)
==31520== by 0x7BC913B3: ??? (signal_i386.c:2700)
==31520== by 0x7BC9143B: call_thread_func (signal_i386.c:2759)
==31520== by 0x7BC91391: ??? (signal_i386.c:2700)
==31520== by 0x7BC9B3EE: start_thread (thread.c:487)
==31520== by 0x4244249: start_thread (pthread_create.c:333)
==31520== by 0x433FD6D: clone (clone.S:114)
==31520==
--
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.
https://bugs.winehq.org/show_bug.cgi?id=38172
Bug ID: 38172
Summary: Smite: Hi-Rez Studios Authenticate and Update Service
fails
Product: Wine
Version: 1.7.37
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ole
Assignee: wine-bugs(a)winehq.org
Reporter: fincer89(a)hotmail.com
Distribution: ---
Created attachment 50922
--> https://bugs.winehq.org/attachment.cgi?id=50922
Smite - installer (InstallSmite.exe) terminal output
The game is not installable due to this issue. The Hi-Rez Studios Update
Service tries to open itself but instead, throws bunch of ole errors in
terminal and fails.
Short terminal output as an attachment.
Long ole backtrace uploaded on dropbox (Wine Bugzilla file size limit
exceeded):
https://www.dropbox.com/s/a56idpskq5hw550/wine_smite_oledebug?dl=1
Windows mode: Win7
Fresh 32-bit wineprefix
winetricks vcrun2008 (required by the game)
--
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.
https://bugs.winehq.org/show_bug.cgi?id=40969
Bug ID: 40969
Summary: Wine: DLL Injection on suspended process provides NULL
arg for static library's DLLMain's lpvReserved value
Product: Wine
Version: 1.9.14
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: aheinerm(a)gmail.com
Distribution: ---
WINE does not respect the behaviour of the lpvReserved argument in DLLMain.
>From the documentation of DllMain
(https://msdn.microsoft.com/en-us/library/windows/desktop/ms682583(v=vs.85).…)
~~~
lpvReserved [in]
If fdwReason is DLL_PROCESS_ATTACH, lpvReserved is NULL for dynamic loads
and non-NULL for static loads.
If fdwReason is DLL_PROCESS_DETACH, lpvReserved is NULL if FreeLibrary has
been called or the DLL load failed and non-NULL if the process is terminating.
~~~~
WINE does NOT respect this behaviour.
# EXAMPLE
Given the following:
A.exe, B.dll, C.dll
C.dll is statically linked from both A.exe and B.dll.
A.exe's process is started and suspended.
B.dll is injected into the A.exe process.
At some point the DllMain of C.dll is called. In WINE, the lpvReserved argument
is NULL, even though C.dll is statically loaded. In Windows 7, 8, and 10, the
lpvReserved argument is non-null.
# REAL WORLD IMPACT
https://github.com/bwapi/bwapi/issues/598https://bugs.winehq.org/show_bug.cgi?id=40259
Blizzard Entertainment's Storm.dll library uses the lpvReserved to invoke a
different behaviour in its DllMain (why, I have no idea). Their video game
Starcraft: Broodwar is statically linked to this library. The third-party hack
DLL called BWAPI.dll is also statically linked to Storm.dll. The Hack launcher
called ChaosLauncher starts and suspends the Starcraft process and injects
various hacks (one being BWAPI). The error in the tracking issue above is
surfaced.
The issue surfaced because Storm performs some alternative initialization logic
that corrupts its ability to function correctly later. In order to temporarily
work around the issue I have forcefully undone the logic made in the other DLL
to cause it to malfunction.
In this case the executable and statically linked library are owned by a
company and their source codes are not available. It should be possible to
reproduce the issue in a more trivial example.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=35533
Bug ID: 35533
Summary: Make it possible to see the sent patch files inline
without extra download step
Product: Wine-Testbot
Version: unspecified
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: unknown
Assignee: wine-bugs(a)winehq.org
Reporter: dmitry(a)baikal.ru
Classification: Unclassified
Currently clicking on a patch file attached to a job leads to a save file
dialog, it would be preferable (at least to me) to be able to see it inline.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=38009
Bug ID: 38009
Summary: winex11.drv does not set NET_WM_STATE_FULLSCREEN if
the display mode was changed
Product: Wine
Version: 1.7.35
Hardware: x86
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: winex11.drv
Assignee: wine-bugs(a)winehq.org
Reporter: stefan(a)codeweavers.com
Distribution: ---
Winex11.drv only sets NET_WM_STATE_FULLSCREEN on a fullscreen game window if
the game uses the monitor resolution that was set when winex11.drv was loaded.
The cause of this is that is_window_rect_fullscreen compares the window
rectangle against the monitor size reported by Xinerama when winex11.drv was
loaded.
This appears to trigger bugs inside Metacity clones and Compiz when creating a
window at a lower resolution. It also breaks the fix that was proposed by a
Marco developer to fix the bug that currently prevents fullscreen windows from
being iconified.
--
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.