https://bugs.winehq.org/show_bug.cgi?id=49793
Bug ID: 49793
Summary: untapped.gg tracker fails to start
Product: Wine
Version: 5.16
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: winehq_bugzilla(a)lxlz.space
Distribution: ---
Created attachment 68109
--> https://bugs.winehq.org/attachment.cgi?id=68109
log on 5.16-staging
Possible regression. I did not investigate this throughly, but it works for me
on 5.12 and does not work on 5.16-staging. Log is in attachment.
--
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=16227
Summary: Tooltips on mouse hover in EMS SQL Manager block the
mouse click
Product: Wine
Version: 1.1.9
Platform: PC-x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P1
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: ksfreitas(a)gmail.com
Created an attachment (id=17473)
--> (http://bugs.winehq.org/attachment.cgi?id=17473)
Screenshot of a tooltip bloocking the mouse click
In EMS SQL Manager (Free and Full), the tooltips block the mouse click, having
to resize to see all item without tooltip for click. The link for freeware
software download:
http://www.sqlmanager.net/en/products/postgresql/manager/download
--
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.
https://bugs.winehq.org/show_bug.cgi?id=50417
Bug ID: 50417
Summary: Multiple game launchers protected by Game Protect Kit
(GPK) crash on startup (dummy PEB->KernelCallbackTable
needed)(Dragon Nest, Age of Wushu)
Product: Wine
Version: 6.0-rc4
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: focht(a)gmx.net
Distribution: ---
Hello folks,
there already exist a small number of bug reports for these games. For example
bug 27716 ("Dragon Nest (Chinese): crashes before login screen") from 2011. I'm
pretty sure the original problem(s) can't be reproduced anymore since the
launcher and protection technology evolved a lot (almost 10 years).
I'm not going to bury my analysis in questionable/messed up bug reports. I did
that mistake many times before.
Anyway, lets hop into this interesting one which took some hours to figure out.
NOTE: When starting the client installer it churns CPU for ~2 minutes until
actually starts installing (extracting files). Just be patient.
--- snip ---
$ pwd
/home/focht/.wine/drive_c/Program Files (x86)/DN/DragonNest
$ WINEDEBUG=+seh,+loaddll,+relay wine ./DNLauncher.exe >>log.txt 2>&1
...
0020:0024:Call KERNEL32.LoadLibraryW(0121d3e8 L"winmm.dll") ret=0309df3c
0020:0024:Ret KERNEL32.LoadLibraryW() retval=01b70000 ret=0309df3c
0020:0024:Call KERNEL32.GetModuleFileNameW(01b70000,0121d11c,00000104)
ret=02f7fec2
0020:0024:Ret KERNEL32.GetModuleFileNameW() retval=0000001d ret=02f7fec2
0020:0024:Call KERNEL32.CreateFileW(0121d11c
L"C:\\windows\\system32\\WINMM.dll",80000000,00000001,00000000,00000003,00000080,00000000)
ret=030a879b
0020:0024:Ret KERNEL32.CreateFileW() retval=000000fc ret=030a879b
0020:0024:Call KERNEL32.GetFileSize(000000fc,0121d118) ret=02f329ff
0020:0024:Ret KERNEL32.GetFileSize() retval=000ae000 ret=02f329ff
0020:0024:Call KERNEL32.VirtualAlloc(00000000,000ae000,00001000,00000040)
ret=0306b045
0020:0024:Ret KERNEL32.VirtualAlloc() retval=03480000 ret=0306b045
0020:0024:Call KERNEL32.ReadFile(000000fc,03480000,000ae000,0121d118,00000000)
ret=02eb9651
0020:0024:Ret KERNEL32.ReadFile() retval=00000001 ret=02eb9651
0020:0024:Call KERNEL32.CloseHandle(000000fc) ret=0300e8bd
0020:0024:Ret KERNEL32.CloseHandle() retval=00000001 ret=0300e8bd
0020:0024:Call KERNEL32.VirtualFree(03480000,00000000,00008000) ret=03091019
0020:0024:Ret KERNEL32.VirtualFree() retval=00000001 ret=03091019
...
--- snip ---
GPK does various consistency checks for loaded modules. The above log snippet
is repeated for a client-coded list of dlls. Since Wine evolved a lot this
year, these kind of checks no longer a problem (bug 15437 et al.)
Disassembly just for documentation in case GPK chokes on one of the few non-PE
"fake" Wine dlls which is currently not the case.
--- snip ---
0300E8CB | bt ax,si |
0300E8CF | sbb ax,bx |
0300E8D2 | push 8000 |
0300E8D7 | btr eax,ecx |
0300E8DA | and ah,E4 |
0300E8DD | shrd ax,dx,52 |
0300E8E2 | push 0 |
0300E8E4 | test ax,6289 |
0300E8E8 | ror ax,9B |
0300E8EC | sbb ah,ch |
0300E8EE | mov eax,dword ptr ds:[ecx+esi+8] | PE->TimeDateStamp disk image
0300E8F2 | test dh,E7 |
0300E8F5 | stc |
0300E8F6 | push esi |
0300E8F7 | cmp eax,dword ptr ds:[edx+ebx+8] | PE->TimeDateStamp loaded dll
0300E8FB | jmp gt.3051676 |
...
03091004 | mov eax,dword ptr ds:[ecx+esi+58] | PE->CheckSum disk image
03091008 | cmc |
03091009 | cmp eax,dword ptr ds:[edx+ebx+58] | PE->CheckSum loaded dll
0309100D | jne gt.305167C |
--- snip ---
Then we arrive at this place:
--- snip ---
...
0024:Call KERNEL32.GetModuleHandleW(0121cfdc
L"C:\\windows\\system32\\kernel32.dll") ret=03058688
0024:Ret KERNEL32.GetModuleHandleW() retval=7b600000 ret=03058688
0024:Call KERNEL32.VirtualAlloc(00000000,00001000,00203000,00000040)
ret=02fc7281
0024:Call
ntdll.NtAllocateVirtualMemory(ffffffff,0121cf6c,00000000,0121cf70,00203000,00000040)
ret=7b0296c1
0024:Ret ntdll.NtAllocateVirtualMemory() retval=00000000 ret=7b0296c1
0024:Ret KERNEL32.VirtualAlloc() retval=02290000 ret=02fc7281
0024:trace:seh:dispatch_exception code=c0000005 flags=0 addr=02E5997A
ip=02e5997a tid=0024
0024:trace:seh:dispatch_exception info[0]=00000000
0024:trace:seh:dispatch_exception info[1]=00000000
0024:trace:seh:dispatch_exception eax=00001000 ebx=7ffde000 ecx=00001000
edx=00001000 esi=00000000 edi=02290000
0024:trace:seh:dispatch_exception ebp=0121d414 esp=0121cfb4 cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00210207
0024:trace:seh:call_vectored_handlers calling handler at 7B00F270 code=c0000005
flags=0
0024:trace:seh:call_vectored_handlers handler at 7B00F270 returned 0
0024:trace:seh:call_stack_handlers calling handler at 02E6E52C code=c0000005
flags=0
0024:Call KERNEL32.GetLastError() ret=02e5d5b5
0024:Ret KERNEL32.GetLastError() retval=00000000 ret=02e5d5b5
...
wine: Unhandled page fault on read access to 00000000 at address 02E5997A
(thread 0024), starting debugger...
--- snip ---
Disassembly of crash site:
--- snip ---
02E59950 | push edi |
02E59951 | push esi |
02E59952 | mov esi,dword ptr ss:[esp+10] | NULL = src buf
02E59956 | mov ecx,dword ptr ss:[esp+14] | 0x1000 = copy count
02E5995A | mov edi,dword ptr ss:[esp+C] | 02290000 = dest buf
02E5995E | mov eax,ecx |
02E59960 | mov edx,ecx |
02E59962 | add eax,esi |
02E59964 | cmp edi,esi |
02E59966 | jbe gt.2E59970 |
02E59968 | cmp edi,eax |
02E5996A | jb gt.2E59CD8 |
02E59970 | bt dword ptr ds:[2EAA834],1 |
02E59978 | jae gt.2E59981 |
02E5997A | rep movsb |
02E5997C | jmp gt.2E59C98 |
02E59981 | cmp ecx,80 |
02E59987 | jb gt.2E59B5B |
02E5998D | mov eax,edi |
02E5998F | xor eax,esi |
02E59991 | test eax,F |
...
02E59C98 | mov eax,dword ptr ss:[esp+C] |
02E59C9C | pop esi |
02E59C9D | pop edi |
02E59C9E | ret |
--- snip ---
Unlike the crash site, most GPK code is heavily obfuscated which makes
debugging a lot more annoying.
I've noticed in one of the earlier checks (gazillion instructions before this
crash) that some PEB fields were of interest to GPK. Instead of spending hours
on debugging non-linear code flows, lots of asm continuations and virtualized
code/registers let the debugger do more work by using some advanced
functionality of debuggers.
Since hardware breakpoints are fast but limited in size I used the much slower
guard page based memory breakpoint type along with a complex break / log
condition on the PEB page.
Address=0x7FFDE000 (PEB)
Range=0x1000 (page)
Condition=(breakif(0), logif(EIP > 0x2E30000 && EIP < 0x10000000, "PEB access
to {$breakpointexceptionaddress} from {EIP}")
What it basically does: the breakpoint triggers on any PEB read access but only
logs if the memory access came from a certain EIP range (where the protection
module is usually mapped), re-arms the guard page and resumes execution.
Turns out being quite unstable, leading to abrupt (silent) process termination
depending when it was armed. I've yet to investigate why. Thread termination /
APC handling seems to play a role.
Anyway, by using a combination of two breakpoints, one for breaking when a
specific dll was loaded and then arming the complex memory breakpoint I got
lucky one time:
--- snip ---
...
DebugString: "FileName:"
DebugString: "C:\Program Files (x86)\DN\DragonNest\gpk\Sddyn_01.dll"
DebugString: "MD5 Value:"
DebugString: "BE47074011E4A04B8C7106EC4FA892EB"
DebugString: "Download MD5 Value:"
DebugString: "BE47074011E4A04B8C7106EC4FA892EB"
DebugString: "Downloaded MD5 Value:"
DebugString: "BE47074011E4A04B8C7106EC4FA892EB"
DebugString: "Download MD5 Value:"
DebugString: "BE47074011E4A04B8C7106EC4FA892EB"
DebugString: "FileName:"
DebugString: "C:\Program Files (x86)\DN\DragonNest\gpk\splash.jpg"
DebugString: "MD5 Value:"
DebugString: "1E0DBD851EB8E88F05D699799BAD7963"
DebugString: "Download MD5 Value:"
DebugString: "1E0DBD851EB8E88F05D699799BAD7963"
DebugString: "Downloaded MD5 Value:"
DebugString: "1E0DBD851EB8E88F05D699799BAD7963"
DebugString: "Download MD5 Value:"
DebugString: "1E0DBD851EB8E88F05D699799BAD7963"
DLL Unloaded: 02250000 gpkup.dll
DLL Loaded: 02250000
Z:\home\focht\projects\wine\mainline-install-6.0-rc4-x86_64\lib\wine\psapi.dll
DLL Loaded: 02E30000 C:\Program Files (x86)\DN\DragonNest\GPK\GT.dll
Breakpoint at 02274080 (DllMain (wintrust.dll)) set!
DLL Loaded: 02260000
Z:\home\focht\projects\wine\mainline-install-6.0-rc4-x86_64\lib\wine\wintrust.dll
DLL Breakpoint (DLL Load and unload): Module wintrust.dll
INT3 breakpoint "DllMain (wintrust.dll)" at <wintrust._DllMainCRTStartup@12>
(02274080)!
Memory breakpoint enabled!
PEB access to 7FFDE02C from 309F6D4
--- snip ---
Disassembly of the offender:
--- snip ---
...
0309F6D0 | mov edx,dword ptr ss:[ebp] | 0x7FFDE02C
0309F6D4 | mov eax,dword ptr ds:[edx] | PEB->KernelCallbackTable
0309F6D6 | add ch,D8 |
0309F6D9 | btr cx,di |
0309F6DD | mov dword ptr ss:[ebp],eax |
0309F6E1 | mov ecx,dword ptr ds:[edi] |
0309F6E3 | jmp gt.307BD90 |
--- snip ---
The pointer was stored in some rather obfuscated place and later ended up as
parameter for the function call that caused the crash.
Wine doesn't implement the concept of 'KernelCallbackTable' hence the field is
NULL by design.
--- snip ---
$ ==> 7FFDE000 00010000
$+4 7FFDE004 00000000
$+8 7FFDE008 00400000
$+C 7FFDE00C 7BC6D2B4 <&ldr>
$+10 7FFDE010 00113430
$+14 7FFDE014 00000000
$+18 7FFDE018 00110000
$+1C 7FFDE01C 7BC6D2E4 <&peb_lock>
$+20 7FFDE020 00000000
$+24 7FFDE024 00000000
$+28 7FFDE028 00000000
$+2C 7FFDE02C 00000000 ; KernelCallbackTable
$+30 7FFDE030 00000000
$+34 7FFDE034 00000000
$+38 7FFDE038 00000000
$+3C 7FFDE03C 00000000
$+40 7FFDE040 7BC6ED64 <&tls_bitmap>
$+44 7FFDE044 0000001F
$+48 7FFDE048 00000000
$+4C 7FFDE04C 00000000
$+50 7FFDE050 00000000
$+54 7FFDE054 00000000
--- snip ---
There are a lot of mysteries and articles about the purpose of this table on
the Internet. Fortunately there is no need to dive into internals /
implementation details. Although it's useful know that 'user32.dll' initializes
the table and provides a number of callbacks to be called from the kernel side.
https://source.winehq.org/git/wine.git/blob/e377786a71c3b6eab5bc11c0b1c9c7c…
For testing purpose I allocated a page in 'process_init' and set the pointer in
'PEB->KernelCallbackTable'. Note, this is not really correct but the protection
doesn't seem to check/care if the table address belongs to 'user32.dll' module.
Furthermore I used my favorite 0xcafebabe pattern to initialize the table
entries. The "magic" pattern serves two purposes:
* allows to determine if any of the entries has been overwritten
* allows to easier identify invocations of callbacks
The latter one is not applicable here since Wine doesn't implement
'KernelCallbackTable' concept. It's still handy in other scenarios.
By using memory (guard page) breakpoints on the newly allocated
'KernelCallbackTable' buffer one can figure out who wants to peek there and for
what reason. Turns out GPK makes a copy of the existing table, hooks one entry
and then sets 'PEB->KernelCallbackTable' to the copy.
--- snip ---
02FA4C6C | test ebp,ebx | EAX = 02290000 = copy
02FA4C6E | mov dword ptr ds:[edx],eax | EDX = 7FFDE02C (KernelCallbackTable)
02FA4C70 | bt ax,sp |
02FA4C74 | stc |
02FA4C75 | mov eax,dword ptr ds:[edi] |
02FA4C77 | stc |
02FA4C78 | add edi,4 |
02FA4C7E | test dx,bp |
02FA4C81 | xor eax,ebx |
02FA4C83 | jmp gt.2F46E4E |
--- snip ---
A memory dump reveals that our nice babe has been "tainted" by a bad guy _oO_
--- snip ---
$ ==> 02290000 CAFEBABE
$+4 02290004 CAFEBABE
$+8 02290008 CAFEBABE
$+C 0229000C CAFEBABE
$+10 02290010 CAFEBABE
$+14 02290014 CAFEBABE
$+18 02290018 CAFEBABE
$+1C 0229001C CAFEBABE
...
$+100 02290100 CAFEBABE
$+104 02290104 CAFEBABE
$+108 02290108 02E44920 ; GPK callback hook
$+10C 0229010C CAFEBABE
$+110 02290110 CAFEBABE
...
$+FF8 02290FF8 CAFEBABE
$+FFC 02290FFC CAFEBABE
--- snip ---
Table entry 0x0108 seems to be of interest to GPK.
The handler is a very long chain of obfuscated code / asm continuations. But
that doesn't matter as of now. It seems the launcher is fine with just being
able to set up a modified copy. Maybe it expects the callback being called at
one point but I ran into couple of other issues.
--- snip ---
02E44920 | E9 17562100 | jmp gt.3059F3C |
...
03059F3C | 55 | push ebp |
03059F3D | 66:C1C5 9A | rol bp,9A |
03059F41 | 9F | lahf |
03059F42 | 8BEC | mov ebp,esp |
03059F44 | F5 | cmc |
03059F45 | 6A FE | push FFFFFFFE |
03059F47 | C1E8 32 | shr eax,32 |
03059F4A | 66:23C2 | and ax,dx |
03059F4D | 68 A860FC02 | push gt.2FC60A8 |
03059F52 | 66:0FB6C0 | movzx ax,al |
03059F56 | 66:0FA4E0 E9 | shld ax,sp,E9 |
03059F5B | 0FBCC7 | bsf eax,edi |
03059F5E | 68 B097E502 | push gt.2E597B0 |
03059F63 | 0AE2 | or ah,dl |
03059F65 | F7C6 D4530E53 | test esi,530E53D4 |
03059F6B | 64:A1 00000000 | mov eax,dword ptr fs:[0] |
03059F71 | 66:3BFD | cmp di,bp |
03059F74 | F8 | clc |
03059F75 | 80F9 B2 | cmp cl,B2 |
03059F78 | 50 | push eax |
03059F79 | 83EC 38 | sub esp,38 |
03059F7C | C0E8 BF | shr al,BF |
03059F7F | C1F0 48 | shl eax,48 |
03059F82 | 53 | push ebx |
03059F83 | 56 | push esi |
03059F84 | 0FABE0 | bts eax,esp |
03059F87 | C0D0 A1 | rcl al,A1 |
03059F8A | 80E4 81 | and ah,81 |
03059F8D | 57 | push edi |
03059F8E | C0E4 AC | shl ah,AC |
03059F91 | A1 207CEA02 | mov eax,dword ptr ds:[2EA7C20] |
03059F96 | 3145 F8 | xor dword ptr ss:[ebp-8],eax |
03059F99 | 66:0FBAF7 3B | btr di,3B |
03059F9E | E9 31040000 | jmp gt.305A3D4 |
...
--- snip ---
By providing a dummy table, the crash is prevented and the launcher runs a bit
further.
It later fails to start a kernel service which seems to be bug 49346. Although
I think the driver issue is now different (half a year later).
--- snip ---
...
00fc:Call KERNEL32.CreateFileW(02e6f9e0
L"\\\\.\\SDGGameLoader",00000000,00000003,00000000,00000003,00000000,00000000)
ret=02ffe7ab
...
00fc:Ret KERNEL32.CreateFileW() retval=ffffffff ret=02ffe7ab
...
00fc:Call KERNEL32.CopyFileW(0121baec L"C:\\Program Files
(x86)\\DN\\DragonNest\\GPK\\gpe2.e",0121c8fc L"C:\\Program Files
(x86)\\DN\\DragonNest\\GPK\\SDGame32.sys",00000000) ret=02fb385f
...
00fc:Ret KERNEL32.CopyFileW() retval=00000001 ret=02fb385f
...
00fc:Call advapi32.CreateServiceW(00193668,02e6fe00 L"SDGame32",02e6fe00
L"SDGame32",000f01ff,00000001,00000003,00000001,0121c8fc L"C:\\Program Files
(x86)\\DN\\DragonNest\\GPK\\SDGame32.sys",00000000,00000000,00000000,00000000,00000000)
ret=02fa6372
...
--- snip ---
Anyway, that would be another story, another day.
To be honest I think making GPK (Game Protect Kit) working with Wine will be
hard, if at all. It's uses pretty much the same techniques like a rootkit /
ring0 malware with kernel and userspace parts.
===
Downloads:
Small "web" downloader:
http://dn.clientdown.sdo.com/Dn_Download/DN_407_downloader_signed.exe
Full client:
http://dn.clientdown.sdo.com/Ver.407Full/DragonNest_v407_Setup.exehttp://dn.clientdown.sdo.com/Ver.407Full/DragonNest_v407.7z.001http://dn.clientdown.sdo.com/Ver.407Full/DragonNest_v407.7z.002http://dn.clientdown.sdo.com/Ver.407Full/DragonNest_v407.7z.003
---
$ sha1sum DN_407_downloader_signed.exe
a42ec8020a3301f621806423154eb69153727a48 DN_407_downloader_signed.exe
$ du -sh DN_407_downloader_signed.exe
3.6M DN_407_downloader_signed.exe
$ sha1sum DragonNest_v407*
833939e2f029e6ec4b20a1048901742087ac24a2 DragonNest_v407.7z.001
9b94d45f95b3e145f1a370b76d51cee9676395f0 DragonNest_v407.7z.002
f2b46a763099848f8e26253811ebc4caf336c11f DragonNest_v407.7z.003
4afc1de3968cf4f3c710a11b7be83f18cb0353d8 DragonNest_v407_Setup.exe
$ du -sh DragonNest_v407*
4.0G DragonNest_v407.7z.001
4.0G DragonNest_v407.7z.002
2.2G DragonNest_v407.7z.003
9.5M DragonNest_v407_Setup.exe
$ wine --version
wine-6.0-rc4
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.
https://bugs.winehq.org/show_bug.cgi?id=50456
Bug ID: 50456
Summary: cannot draw non-client area
Product: Wine
Version: 6.0-rc4
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: chenhaoyang(a)uniontech.com
Distribution: ---
Created attachment 69070
--> https://bugs.winehq.org/attachment.cgi?id=69070
IDE:visual c++ 2008 express edition
cannot draw non-client area.Because the size of the non-client area is
incorrect.
--
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=50000
Bug ID: 50000
Summary: wineconsole F8
Product: Wine
Version: 5.19
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: vladimir.kokovic(a)gmail.com
Distribution: ---
Created attachment 68408
--> https://bugs.winehq.org/attachment.cgi?id=68408
Exception backtrace
Start wineconsole
Type next cmds:
ver
dir
echo %path%
d & F8 --> Unhandled exception
Unhandled exception: page fault on read access to 0x00000000 in 64-bit code
(0x0000000000401cbe).
Vladimir Koković, DP senior(70),
Serbia, Belgrade, 13.October 2020
--
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=50451
Bug ID: 50451
Summary: RISE Editor takes a long time to start up
Product: Wine-staging
Version: 5.22
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: eli(a)meluc.ci
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
Created attachment 69066
--> https://bugs.winehq.org/attachment.cgi?id=69066
Log messages for RISEEditor.exe
This is one of those ClickOnce apps.
The program can be downloaded from
http://www.risetobloome.com/clickonce/riseeditor/riseeditor.htm , the
RISEEditor.application file can then be started with wine start
RISEEditor.application provided dotnet40 is installed.
After installation, the actual executable is placed in some directory under
"C:/Users/$user/Local Settings/Application Data" and can be started directly
from there.
Starting up the actual application takes a very long time; it hits some sort of
timeout I guess. I've attached the log.
It hangs right after printing line 38,
"0024:fixme:virtual:NtFlushProcessWriteBuffers stub"
--
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=38966
Bug ID: 38966
Summary: force close after hitting install usb drivers on lg
mobile support tool and when enter cell carrier
Product: Wine
Version: 1.7.37
Hardware: x86
OS: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: catsetname(a)yahoo.com
Created attachment 51910
--> https://bugs.winehq.org/attachment.cgi?id=51910
backtrace.txt
after loading lg mobile support tool i hit install usb drivers, list of cell
carriers pop to select once selected box comes up stating program needs to
close and options to close or show details
--
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=27502
Summary: app freezes when WM_KILLFOCUS creates modal dialog
Product: Wine
Version: unspecified
Platform: All
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: efrias(a)syncad.com
Created an attachment (id=35159)
--> (http://bugs.winehq.org/attachment.cgi?id=35159)
simple example which produces the error
When a program brings up a modal dialog box in response to a WM_KILLFOCUS
message, the program will freeze. I've attached a simple test case, all
boilerplate except for:
case WM_KILLFOCUS:
MessageBox(hWnd, _T("Killing Focus"), _T("Note"), MB_OK);
in the main event loop. If you run the program and then give focus to another
application, the messagebox will pop up and then the program will become
unresponsive.
What is happening is:
- x11drv gets a FocusOut event and calls the event handler, which ends up
SendMessage-ing a WM_KILLFOCUS to the program.
- The programs's code creates a modal dialog like the MessageBox above, and
enters the dialog's event loop, which winds up calling GetMessage which calls
MsgWaitForMultipleObjectsEx to get more X11 events.
- X11DRV_MsgWaitForMultipleObjectsEx executes this:
if (data->current_event) mask = 0; /* don't process nested events
*/
where data->current_event is true since we're still handling the FocusOut
event. Since we're not processing nested events, we'll never be able to
process the usual events like keys or mouse events which could exit this nested
event loop.
This type of error occurs in a few places in our application, where a
WM_KILLFOCUS message to an edit box triggers some input validation and displays
an error on failure. This works correctly in the normal case, where the user
tabs out or clicks on another control in the dialog box containing the edit
control -- since everything stays in the same top-level window, there is no
FocusOut event from X11 and the WM_KILLFOCUS is generated internally by wine in
response to, say, a KeyEvent. I think these key or mouse events are just
posted to the windows message queue, and the X11 event handler has already
exited by the time the application gets around to processing the ensuing
WM_KILLFOCUS. But in the case where focus is lost by clicking outside the
dialog containing the edit control, the WM_KILLFOCUS is generated by the
FocusOut handler which is still executing, and we lock up.
I suspect this is related to bug 11595 "Notepad++ freezes if native application
changes a file it has open (dogfood)". My guess is in that case, a FocusIn
event triggers something like a WM_ACTIVATE, in which notepad++ notices a file
is changed and displays a messagebox asking if you want to reload. Since wine
is still processing the FocusIn event, the modal message loop's call to
MsgWaitForMultipleObjectsEx will never process any useful events because it's a
nested event. Our application's built-in text editor has this same problem.
I don't understand the event handling code well enough to propose a solution.
As a test, I allowed nested event processing and it solved the problem without
introducing any obvious errors, but I'm sure that check was in there for a
reason. It's probably better to keep the application code from being executed
from inside the event handler, if that's possible.
Note: this bug was also posted as a message to wine-devel here:
http://www.winehq.org/pipermail/wine-devel/2011-June/090652.html
--
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.
https://bugs.winehq.org/show_bug.cgi?id=50444
Bug ID: 50444
Summary: Text not shown/drawn or hidden starting in Wine 5.18
Product: Wine
Version: 5.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: support(a)htmlvalidator.com
Distribution: ---
Created attachment 69057
--> https://bugs.winehq.org/attachment.cgi?id=69057
The validation pane (the left-side wide window at screen bottom) as displayed
when running CSS HTML Validator under Wine 3 through Wine 5.17.
POSTING this bug report from a CSS HTML Validator user that uses and test CSS
HTML Validator under Wine.
Going back to at least Wine 3, the CSS HTML Validator validation pane has
always displayed correctly until Wine 5.18, when the upgrade from Wine 5.17 to
Wine 5.18 resulted in the validation pane always displaying blank. The
validation pane is located at the bottom of the full CSS HTML Validator window.
See the attached screenshots, I cropped out most of the upper part of the full
CSS HTML Validator window.
--
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=50442
Bug ID: 50442
Summary: WW2 Online: Fractional scaling causes mouse clicks not
registering
Product: Wine
Version: 6.0-rc4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ilgaz(a)fastmail.fm
Distribution: ---
Created attachment 69054
--> https://bugs.winehq.org/attachment.cgi?id=69054
output of console
I have openSUSE Tumbleweed here with wine-staging installed and "full wayland"
enabled. I have scaled my 1080p monitor using KDE's scaling to 120% and it
displays 1600x900 in resolution screen.
ww2 online launches fine and when I click "OK" button on a dialogue represented
at startup, nothing happens.
When I disable scaling and use raw 1080p resolution, everything works fine.
Game can be downloaded/played free/ required no "winetricks" whatsoever until
today.
https://www.wwiionline.com/
--
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=32058
Bug #: 32058
Summary: Guild Wars 2 launcher freezes/hangs (unable to launch
game)
Product: Wine
Version: 1.5.15
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: x.egam.wodahs.x(a)gmail.com
CC: julliard(a)winehq.org
Classification: Unclassified
Once I updated wine to version 1.5.15, the Guild Wars 2 launcher can no longer
launch the game because it just freezes/hangs. This was not an issue in 1.5.14,
and in order to run the game for now I'm using wine 1.5.14 compiled from
source.
In wine 1.5.14, the launcher is black (can't see UI at all, but it's still
functional) unless using the -dx9single flag. Using -dx9single, the background
is black instead of transparent but the UI inside is properly rendered. This
information is important because, before submitting this bug report, I
performed two separate git bisects between 1.5.14 and 1.5.15: one without any
command-line parameters, and one using -dx9single.
Technical details follow:
=======================================================================
1) git bisect for running the game without any parameters:
In the last good commit (8dcbeff760115834656f3f1fc85922e3a9af14d0), the
launcher is still black but it still works. You cannot see the UI but by
blindly logging in, the game does launch. In the first bad commit
(f12c1c6630f0bf842dde9af10da4ab188ff16e94), the behavior is different from the
wine 1.5.15 release and the other commits tested: here, instead of locking up,
the window just disappears. It's still there, but I guess it's fully
transparent. Because this leaves us even more "blind", I considered this "bad"
in the git bisect, yielding the following result:
---
f12c1c6630f0bf842dde9af10da4ab188ff16e94 is the first bad commit
commit f12c1c6630f0bf842dde9af10da4ab188ff16e94
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Wed Sep 26 13:12:17 2012 +0200
winex11: Switch to an ARGB visual for layered windows with per-pixel alpha.
:040000 040000 e9933c28f3e50c52d2cee37a43b06a2f5cb5a497
3870099a31a68a69cd7c022857794700c2343aa9 M dlls
---
If, however, we consider f12c1c6630f0bf842dde9af10da4ab188ff16e94 "good" in the
git bisect, we get:
---
d8247efd5ecb8c4604624eb2bbf47e194ce59e7e is the first bad commit
commit d8247efd5ecb8c4604624eb2bbf47e194ce59e7e
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Thu Sep 27 20:47:08 2012 +0200
winex11: Take the alpha channel into account to compute the region of
layered windows.
:040000 040000 3870099a31a68a69cd7c022857794700c2343aa9
d9ec62b63405f910db90b095145a7910cc124eef M dlls
---
In this case, the launcher does indeed lock up in the first bad commit
(d8247efd5ecb8c4604624eb2bbf47e194ce59e7e).
2) git bisect for running the game using -dx9single:
Using the -dx9single flag, we seem to be able to get to a later commit before
it stops working (but does not work in the 1.5.15 release). In the last good
commit (dbff4f422c943a837f0098e921f831eb4a94ac11), everything seems to be fine
(when using the -dx9single flag) and even the transparency seems to be working.
However, in the first bad commit (6f3b097a203d9ca248732cb45eed462599ca3af1),
things start to lock up. This yields the following git bisect result:
---
6f3b097a203d9ca248732cb45eed462599ca3af1 is the first bad commit
commit 6f3b097a203d9ca248732cb45eed462599ca3af1
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Wed Oct 3 00:09:01 2012 +0200
winex11: Fix a typo in the surface region computation with an alpha
channel.
:040000 040000 fa11ac3c80763b81911ba999d8302029d2c6d147
566c9c06b11f8785c870a1e09ec53d42e13d1524 M dlls
---
--
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.
https://bugs.winehq.org/show_bug.cgi?id=38166
Bug ID: 38166
Summary: Heroes of Might and Magic 5 slowly on some maps.
Product: Wine
Version: 1.7.37
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: galdralag(a)bk.ru
Distribution: ---
On some maps especially when many green trees game works very slowly.
This happens on all versions of nvidia driver AFTER 331.89.
331.89 it is last version when game works on maximum video settings.
May be this is bug of nvidia driver (not wine) but I can't test this.
I tested 2 videocards nvidia 760M and 650 ti.
This can be reproduced on ArchLinux, Fedora, OpenSuse and Kubuntu.
If you have problems with reproducing I can attach some maps where it can be
reprocuced
--
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=50304
Bug ID: 50304
Summary: Control-C exits winedbg instead of stopping the
inferior
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winedbg
Assignee: wine-bugs(a)winehq.org
Reporter: joachim.priesner.bugs(a)web.de
CC: jacek(a)codeweavers.com
Regression SHA1: 633b244b1ae7928cafbfd25ef338e4918aac0d74
Distribution: ---
Created attachment 68875
--> https://bugs.winehq.org/attachment.cgi?id=68875
+winedbg log of hang behavior
To reproduce:
- run wine winedbg program.exe
- press "c <Enter>" to run the program
- press Control-C
Expected: The program is stopped and I am back at the winedbg prompt.
Actual:
The behavior matched the expected one until the following commit:
commit 54e117018cd4cc58c258da92686bfad13946bde2
Author: Jacek Caban <jacek(a)codeweavers.com>
Date: Mon Sep 21 17:07:29 2020 +0200
kernelbase: Use conhost to handle Unix consoles.
Starting at this commit, pressing Control-C would cause winedbg to hang (needed
to "kill -9" it).
The behavior changed again in the following commit:
commit 633b244b1ae7928cafbfd25ef338e4918aac0d74
Author: Jacek Caban <jacek(a)codeweavers.com>
Date: Tue Oct 13 16:27:38 2020 +0200
kernel32: Always use conhost for ReadConsoleW.
Starting at this commit, and until the current master, pressing Control-C
causes winedbg to immediately exit.
--
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=49356
Bug ID: 49356
Summary: failed to load while trying to run game
Product: Wine
Version: 1.8.6
Hardware: x86
OS: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: ivan_kalis(a)hotmail.com
Created attachment 67401
--> https://bugs.winehq.org/attachment.cgi?id=67401
backtrace i was given when it crashed
i ran the game and it seemed to work until i went to the launcher of the game
which i assume was the windows launcher and it crashed right afterwards with
this message given to me
--
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=50420
Bug ID: 50420
Summary: Divinity: Original Sin - Enhanced Edition crashes on
startup
Product: Wine
Version: 5.11
Hardware: x86-64
URL: https://store.steampowered.com/app/373420/Divinity_Ori
ginal_Sin__Enhanced_Edition/
OS: Linux
Status: NEW
Keywords: regression
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: gyebro69(a)gmail.com
CC: julliard(a)winehq.org
Regression SHA1: df5e4764870e8ad1d8b206cb3475a073bc034e48
Distribution: ArchLinux
Created attachment 69038
--> https://bugs.winehq.org/attachment.cgi?id=69038
terminal output
The game shows a black screen then it crashes (just before the developer logo
would show up).
Reproduced with the GOG and the Steam version.
According to my testing the last working Wine version was 5.10.
The commit when the problem appeared:
df5e4764870e8ad1d8b206cb3475a073bc034e48
ntdll: Move the current directory initialization to the Unix library.
Still present in wine-6.0-rc4-6-gff09f14867e.
--
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=44243
Bug ID: 44243
Summary: Spire and Serum paints very slowly
Product: Wine
Version: 3.0-rc3
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: bique.alexandre(a)gmail.com
Distribution: ---
Hi,
The following programs take a lot of time to render the UI:
https://www.reveal-sound.com/https://www.xferrecords.com/products/serum
A few versions before the UI was just black, and recently it started to paint
correctly, so it must be that you have add new painting/rendering api recently.
Yet the painting performance is really slow, so it would be great if you guys
could have a look and optimize it a bit? Maybe it is an easy thing to do?
Many thanks for your work guys!
To reproduce it you can install a plugin host like reaper:
https://www.reaper.fm/ and then install the vst plugins and try them with
reaper.
Regards,
Alexandre
--
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=21987
Summary: Acrobat 7 tryout complains: This Postscript Driver or
Windows Platform (Win9x/Me) not supported
Product: Wine
Version: 1.1.40
Platform: x86
URL: http://www.adobe.com/products/acrobatpro/tryreg.html
OS/Version: Linux
Status: NEW
Keywords: download
Severity: enhancement
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jeffz(a)jeffz.name
When installing the Acrobat 7 trial AcTR7EFG.exe, the installer produces a
dialog:
Devmode
This Postscript Driver or Windows Platform (Win9x/Me) not supported
It doesn't prevent the installer from progressing, but the same thing doesn't
happen on Vista.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=50241
Bug ID: 50241
Summary: Vertical Text in NL5 schematic doesn't display
correctly
Product: Wine
Version: 5.22
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: rmm(a)cantrip.org
Distribution: ---
Created attachment 68751
--> https://bugs.winehq.org/attachment.cgi?id=68751
Should show R5 and 10e+6 vertically
Hi All,
NL5 circuit simulator has worked very well in Wine for years. A change in Wine
5.22 or possibly 5.21 has broken vertical text rendering. It shows up at a 45
degree angle instead, with strange spacing.
I'm running Wine 5.22 (Fedora packages) on Fedora 32. I will attach an
image...
Unfortunately I can't seem to revert back to 5.21 or 5.20 using DNF (without
jumping through a lot of hoops) to show you what it should look like.
I've reached out to the developer and he said the code that rotates the text
uses the LOGFONT structure to set the orientation of the text:
if ( textdir != 0 ) {
LOGFONT lf; // Windows native font structure
ZeroMemory(&lf, sizeof(LOGFONT));
lf.lfHeight = Canvas->Font->Height;
lf.lfEscapement = (4-textdir)*900; // degrees to rotate
lf.lfOrientation = (4-textdir)*900;
lf.lfCharSet = DEFAULT_CHARSET;
strcpy(lf.lfFaceName, Canvas->Font->Name.c_str() );
Canvas->Font->Handle = CreateFontIndirect(&lf);
}
So something deep down in there changed in 5.21 or 5.22.
An older bug, #14199 mentions that a similar problem was in gdi32.
Thanks,
Richard
--
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=50423
Bug ID: 50423
Summary: dlls/devenum/mediacatenum.c: | function
‘property_bag_Read’ | error: unknown field ‘cPins2’
specified in initializer
Product: Wine
Version: 6.0-rc4
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: version2013(a)protonmail.com
Distribution: ---
Created attachment 69040
--> https://bugs.winehq.org/attachment.cgi?id=69040
log.txt
in distro:
# uname --kernel-release
3.0.66
# gcc --version
4.3.4
# ldd --version
2.10.1
applying patch from https://bugs.winehq.org/show_bug.cgi?id=47907#c12
Compiling wine-6.0-rc4 fails with multiple items:
In function ‘property_bag_Read’:
error: unknown field ‘cPins2’ specified in initializer
error: unknown field ‘rgPins2’ specified in initializer
config line:
configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
--x-includes=/usr/X11R7/include --x-libraries=/usr/X11R7/lib --with-x
--libdir=/usr/lib32 CFLAGS="-O2 -march=i686 -mtune=i686"
--
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=50408
Bug ID: 50408
Summary: wineboot crash to due getaddrinfo() returning NULL
ai_canonname
Product: Wine
Version: 6.0-rc4
Hardware: x86-64
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P2
Component: winsock
Assignee: wine-bugs(a)winehq.org
Reporter: damjan.jov(a)gmail.com
After the WINEPREFIX is created, wineserver exits, and any Wine application is
run, wineboot crashes with this error and incorrect stack trace:
Unhandled exception: page fault on read access to 0x00000000 in 32-bit code
(0x70bab1d7).
Register dump:
CS:0033 SS:003b DS:003b ES:003b FS:0013 GS:001b
EIP:70bab1d7 ESP:0075f008 EBP:0075f008 EFLAGS:00010246( R- -- I Z- -P- )
EAX:00000000 EBX:0075f6e0 ECX:0000002e EDX:003e2034
ESI:00000000 EDI:0075f4d8
Stack dump:
0x0075f008: 0075fef8 0040633d 00000000 0000002e
0x0075f018: 0075f4d8 0075f094 00000000 00020006
0x0075f028: 00000000 0075f6e0 00000000 00000000
0x0075f038: 00000000 00000000 00000000 00000000
0x0075f048: 00000000 004508e0 0075f094 7bc0c0b0
0x0075f058: 7b632328 7bc2a280 00000034 0075f4d8
Backtrace:
=>0 0x70bab1d7 memcmp+0x107(ptr2=<is not available>, n=<is not available>)
[Z:\home\user\Wine\wine\dlls\msvcrt\string.c:2602] in ucrtbase (0x0075f008)
1 0x0040633d main+0x151c(argv=<is not available>)
[Z:\home\user\Wine\wine\programs\wineboot\wineboot.c:829] in wineboot
(0x0075fef8)
2 0x004042d8 mainCRTStartup+0x67()
[Z:\home\user\Wine\wine\dlls\msvcrt\crt_main.c:58] in wineboot (0x0075ff30)
3 0x7b62ddf0 WriteTapemark+0xff(type=<is not available>, count=<is not
available>, immediate=<is not available>)
[Z:\home\user\Wine\wine\dlls\kernel32\tape.c:317] in kernel32 (0x0075ff48)
4 0x7bc56b97 RtlSleepConditionVariableSRW+0x226(lock=<is not available>,
timeout=<is not available>, flags=<is not available>)
[Z:\home\user\Wine\wine\dlls\ntdll\sync.c:557] in ntdll (0x0075ff5c)
5 0x7bc56e40 call_thread_func+0xaf(arg=0x3fe000)
[Z:\home\user\Wine\wine\dlls\ntdll\thread.c:134] in ntdll (0x0075ffec)
0x70bab1d7 memcmp+0x107 [Z:\home\user\Wine\wine\dlls\msvcrt\string.c:2602] in
ucrtbase: movzbl 0x0(%eax),%edx
2602 if (*str == (char)c) return (char*)str;
Modules:
Module Address Debug info Name (8 modules)
PE 400000- 450000 Dwarf wineboot
PE 61740000-61802000 Deferred advapi32
PE 62790000-62794000 Deferred ws2_32
PE 6bc00000-6bc79000 Deferred sechost
PE 70b40000-70d77000 Dwarf ucrtbase
PE 7b000000-7b2a2000 Deferred kernelbase
PE 7b600000-7b8f6000 Dwarf kernel32
PE 7bc00000-7be33000 Dwarf ntdll
Threads:
process tid prio (all id:s are in hex)
00000020
00000024 0
00000028 (D) C:\windows\system32\wineboot.exe
0000002c 0 <==
00000038 0
0000003c explorer.exe
00000040 0
00000044 0
00000048 0
System information:
Wine build: wine-6.0-rc2-43-gef876fc54e2
Platform: i386
Version: Windows 7
Host system: FreeBSD
Host version: 12.2-RELEASE
--
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=48142
Bug ID: 48142
Summary: shell32:appbar tests fail on some Windows 10 machines
Product: Wine
Version: 4.20
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: shell32
Assignee: wine-bugs(a)winehq.org
Reporter: madewokherd(a)gmail.com
https://test.winehq.org/data/tests/shell32:appbar.html
Some of the "cw" win10 machines fail in shell32:appbar. Mine happens to work
when running the test on its own. I haven't been able to find a pattern, other
than that none of the machines are on the current build.
Without a machine that can reproduce this, I don't see a way to figure out
what's going on.
It would seem based on the results that appbar functionality does not work at
all.
One possibility is that a previous test leaves explorer in a bad state. If so,
running the test on its own should succeed. It would also explain the
correlation between failures here and in shell32:systray
https://test.winehq.org/data/a9c4b309f6af82b624604bd0df898ad88d59ab5a/index…
--
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=43852
Bug ID: 43852
Summary: Monkey Island Special Edition Collection: White screen
and crash when starting Monkey1.exe
Product: Wine
Version: 2.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: cweiske(a)cweiske.de
Distribution: ---
Created attachment 59408
--> https://bugs.winehq.org/attachment.cgi?id=59408
wine terminal output
After successfully installing "Monkey Island Special Edition Collection" from
DVD (bug #43851), running Monkey1.exe fails:
1. The main display (or wine's virtual desktop) only shows a white screen
2. Terminal shows some errors, the last ones are below
3. Wine's in-built backtrace collector does not seem to work
err:ole:COMPOBJ_DllList_Add couldn't load in-process dll
L"C:\\windows\\system32\\XAudio2_4.dll"
err:ole:CoGetClassObject no class object {03219e78-5bc3-44d1-b92e-f63d89cc6526}
could be created for context 0x1
wine: Unhandled page fault on read access to 0x00000000 at address 0x441192
(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=47824
Bug ID: 47824
Summary: Remote Life demo terminates with 'Cannot load library
nw_elf.dll'
Product: Wine
Version: 4.17
Hardware: x86-64
URL: https://nextgamelevel.itch.io/remote-life
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: vulture6(a)mail.com
Distribution: Mint
Remote Life 1.2 demo terminates with 'Cannot load library nw_elf.dll'
The only other output is '0020:err:plugplay:load_function_driver AddDevice
failed for driver L"winebus", status 0xc0000002.'
Graphics card is Nvidia.
--
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=50397
Bug ID: 50397
Summary: dlls/d3dcompiler_43/tests/hlsl_d3d11.c: error: unknown
field ‘Texture2D’ specified in initializer
Product: Wine
Version: 6.0-rc3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: version2013(a)protonmail.com
Distribution: ---
Created attachment 69018
--> https://bugs.winehq.org/attachment.cgi?id=69018
log.txt
in distro:
# uname --kernel-release
3.0.66
# gcc --version
4.3.4
# ldd --version
2.10.1
applying patch from https://bugs.winehq.org/show_bug.cgi?id=50378#c2
wine-6.0-rc3 compilation stops at new bug:
In function ‘test_sampling’:
error: unknown field ‘Texture2D’ specified in initializer
--
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=49771
Bug ID: 49771
Summary: Segfault running exception tests
Product: Wine
Version: 5.16
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: jeffersoncarpenter2(a)gmail.com
Distribution: ---
Created attachment 68085
--> https://bugs.winehq.org/attachment.cgi?id=68085
Valgrind output
Steps to reproduce:
* Check out wine-5.16 and build. Configure output attached.
* cd dlls/ntdll/tests
* ../../../loader/wine ./ntdll_test.exe.so exception
Attached valgrind output.
--
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.