https://bugs.winehq.org/show_bug.cgi?id=56935
Bug ID: 56935
Summary: Softube VST plugins are not drawing their UI
Product: Wine
Version: 9.12
Hardware: x86-64
URL: https://www.softube.com/
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: dwmapi
Assignee: wine-bugs(a)winehq.org
Reporter: notasas(a)gmail.com
CC: jzeng(a)codeweavers.com
Regression SHA1: f397807415b4807aeabac7243a13a15599008ee7
Distribution: ---
The plugin UI never updates, it's window is cleared with black on startup and
then it just shows the remains of anything that was ever drawn over it, like
unrelated windows. With the commit is reverted everything redraws normally.
Softube provides a free plugin that reproduces the issue ("Saturation Knob"),
but sadly it's not very straightforward to set it up. First you need some DAW
software what can run windows VST plugins through wine, like lmms. Then Softube
doesn't provide it's plugins directly but insists on installing them through
their bloated downloader, which then insists to install several licensing
services. I could not get it to work through wine and used a windows vm for
that part. Once you get the plugin dll however everything works through wine,
including "activation" (even for a free plugin) except that the UI is not
updating.
--
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=53542
Bug ID: 53542
Summary: Hog4PC 3.17 installer VBScript custom action needs
IWshShell::Run to return signed type.
Product: Wine
Version: 7.11
Hardware: x86-64
URL: https://web.archive.org/web/20211128125004/https://cdn
.etcconnect.com/Hog_4_PC_3.17.0.3327.msi.zip
OS: Linux
Status: NEW
Keywords: download, Installer, patch
Severity: normal
Priority: P2
Component: wshom.ocx
Assignee: wine-bugs(a)winehq.org
Reporter: sloper42(a)yahoo.com
CC: focht(a)gmx.net, sloper42(a)yahoo.com, temp82(a)luukku.com
Depends on: 52128
Distribution: ---
+++ This is successor to Bug #52128 +++
After applying scrrun::Movefolder patch, we get script error in msi custom
action
$WINEDEBUG=+vbscript ./wine msiexec -i C:\Hog_4_PC_3.17.0.3327.msi
...
01c4:trace:vbscript:do_icall L"unpack1" 0
01c4:trace:vbscript:interp_int 0
01c4:trace:vbscript:interp_equal
01c4:trace:vbscript:var_cmp 0017A75C {VT_UI4: 0} 00176FB8 {VT_I2: 0}
01c4:trace:vbscript:VBScriptError_GetExceptionInfo (0017AE58)->(03D0FB10)
01c4:err:msi:MsiActiveScriptSite_OnScriptError script error: L"Type mismatch"
Excerpt from script file:
...
Set objShell = CreateObject("Shell.Application")
...
firstCmd = """" & TargetDir & "\7za.exe"" x -y " & """" & FixtureLib &
"""" & " -o""" & FixtureLibDir & """"
unpack1 = shell.Run(firstCmd, 0, True)
If ( unpack1 = 0 ) Then
...
Return value of shell.Run is of type VT_UI4 which is no integrated type of
vbscript.
Output value of IWshShell::Run [out, retval] DWORD* out_ExitCode)
seems to be int* in native and not DWORD* as in wine.
--
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=54670
Bug ID: 54670
Summary: 16-bit applications fail in wow64 mode
Product: Wine
Version: 8.0
Hardware: x86-64
OS: Linux
Status: NEW
Keywords: download, Installer, wow64
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: austinenglish(a)gmail.com
Distribution: Debian
$ wineserver -k ; rm -rf ~/.wine ; WINE=/opt/oldwownew/wine-8.0/bin/wine
winetricks -q icodecs
------------------------------------------------------
Executing load_icodecs
Executing cabextract -q -d
/home/austin/.wine/dosdevices/c:/windows/temp/codinstl/
/home/austin/.cache/winetricks/icodecs/codinstl.exe
Executing cd /home/austin/.wine/dosdevices/c:/windows/temp/codinstl/
Executing /opt/oldwownew/wine-8.0/bin/wine setup.exe /s
0284:err:environ:init_peb starting L"C:\\windows\\syswow64\\winevdm.exe" in
experimental wow64 mode
0284:fixme:wow:wow64_NtSetLdtEntries 0107 02d0323f 0100f338 0000 00000000
00000000: stub
0284:err:module:LdrInitializeThunk "krnl386.exe16" failed to initialize,
aborting
0284:err:module:LdrInitializeThunk Initializing dlls for
L"C:\\windows\\syswow64\\winevdm.exe" failed, status c0000005
------------------------------------------------------
--
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=54626
Bug ID: 54626
Summary: Saving files in Microsoft Word/Excel 2010 creates
useless shortcut files
Product: Wine
Version: 8.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: shell32
Assignee: wine-bugs(a)winehq.org
Reporter: kle(a)bluewin.ch
Distribution: ---
Here follows a new bug report regarding the problem observed in old bug report
15480.
It was told me that I should open a new bug report. ;-)
Okay, the issue regarding the creation of useless shortcut files is back in
Wine 8.0 (stable).
When I open a *.xlsx file at the desktop and save it (with the same name) to an
*.ods file then Excel 2010 will create two files. One is a *.lnk (which points
to the original xlsx) and the other is a shortcut regarding the ods file but
also with *.ods ending.
As mentioned, both of them are non-functional.
--
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=54925
Bug ID: 54925
Summary: World of Warcraft WotLK Classic crashes on receiving
inputs very frequently
Product: Wine
Version: 8.7
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: chagatai(a)bitigchi.xyz
Distribution: ---
Created attachment 74446
--> https://bugs.winehq.org/attachment.cgi?id=74446
wine debug log
After logging in and selecting a character the game seems to run as normal
without issues. If I don't do anything and just leave the game as is without
inputs it runs for quite a while without issue. But without fail, if I start
making inputs the game crashes within a minute or two.
Most of the debug log is just this one line:
010c:err:sync:RtlLeaveCriticalSection section 0000000000FD26C0 (null) is not
acquired
And when the application stops responding it's:
01d4:err:sync:RtlpWaitForCriticalSection section 0000000000FD26F0 (null) wait
timed out in thread 01d4, blocked by 0000, retrying (60 sec)
At which point the application stops responding and I'm forced to terminate it.
--
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=54508
Bug ID: 54508
Summary: psapi:psapi_main - The 64-bit
test_EnumProcessModulesEx() gets unexpected snapshot
counts on Windows 7 and 11
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: psapi
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
psapi:psapi_main - The 64-bit test_EnumProcessModulesEx() gets unexpected
snapshot counts on Windows 7 and 11:
w7pro64:
psapi_main.c:483: Test failed: pcs-6432: Wrong count 23 in C:\Windows\SysWOW64
psapi_main.c:488: Test failed: pcs-6432: Wrong count 2 in C:\Windows\system32
w11pro64:
psapi_main.c:488: Test failed: pcs-6432: Wrong count 0 in C:\Windows\system32
See https://test.winehq.org/data/patterns.html#psapi:psapi_main
These failures don't happen on Windows 8 to Windows 10!
These tests and failures were introduced in the following commit:
commit e38455a2181ab5ce0bf842f2c9a638b3ee9b538c
Author: Eric Pouech <eric.pouech(a)gmail.com>
AuthorDate: Tue Feb 14 11:06:57 2023 +0100
psapi/tests: Test directory of enumerated loaded modules.
Showing that Wine incorrectly reports, for a Wow64 process, the system
DLLs from within the wow64 directory while they should be from system32.
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.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.
https://bugs.winehq.org/show_bug.cgi?id=54436
Bug ID: 54436
Summary: wine-staging-8.0 regression (not working): Command &
Conquer 3: Tiberium Wars Kane's Wrath
Product: Wine-staging
Version: 8.0
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: kolAflash(a)kolahilft.de
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
Created attachment 73981
--> https://bugs.winehq.org/attachment.cgi?id=73981
wine-staging-8.0: left is fine, right is broken
With wine-staging-7.0 "Command & Conquer 3: Tiberium Wars Kane's Wrath" was
working fine.
In wine-8.0 and wine-staging-8.0 it's broken.
With wine-staging-8.0 the menu looks broken.
See attached screenshot. (left is fine, right is broken)
With wine-8.0 the menu loads, but starting a skirmish game crashes the
application. There's an error dialog window saying:
Direct3D error 0x8007000e (E_OUTOFMEMORY)
--
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=21483
Summary: changed token security breaks .NET Framework SDK tools
Product: Wine
Version: 1.1.33
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wineserver
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
some of Microsoft's tools from .NET Framework SDKs - namely managed debuggers
(CLR) - stopped working after 1.1.33+ release. They seem to be very picky about
object security.
I bisected this one but technically this isn't a regression because Rob's token
patches made Wine more correct - exposing another object security problem.
--- snip ---
$ git bisect bad
bd56916f90e68632993a7275fe30a55a7efa222a is the first bad commit
commit bd56916f90e68632993a7275fe30a55a7efa222a
Author: Rob Shearman <robertshearman(a)gmail.com>
Date: Mon Nov 16 20:11:06 2009 +0000
server: Extend get_token_user server call to also retrieve SIDs for the
token's owner or primary group.
:040000 040000 829f1543526675ae48f6fde8c8cedff74fd51797
7a77653291795c209ec529dd6660d52fc922a58c M dlls
:040000 040000 57735b53b28db37ac4627dc009000e225175164a
4dcc1388cb136e559c06106632c08e8e610fe557 M include
:040000 040000 4e83227cb0133c7e288a1e930461d4efe1130882
cf1c3539d6b3c91c854fa2b9b672f68ea601f639 M server
--- snip ---
"old" behaviour, where default process token was like this:
Token owner -> S-1-5-4 "NT AUTHORITY\INTERACTIVE" (well-known group)
Token user -> S-1-5-4 "NT AUTHORITY\INTERACTIVE" (well-known group)
Token primary group -> S-1-5-32-544 "BUILTIN\Administrators" (alias)
NtQueryInformationToken had the token owner info hard-coded (to
SECURITY_INTERACTIVE_RID) while Rob's patches moved the actual query to
wineserver.
---
Basically the app code that verifies the security of created objects goes like
this:
- get SD from created object (event) handle -> GetKernelObjectSecurity(
OWNER_SECURITY_INFORMATION | DACL_SECURITY_INFORMATION)
- get owner SID of SD -> GetSecurityDescriptorOwner() -> SID1
- get DACL of SD -> GetSecurityDescriptorDacl()
- for each ACE from DACL (GetAce) -> SID2: check ACE SID against SD owner SID
-> EqualSid( SID1, SID2)
- match -> profit! not -> fail!
--- snip ---
...
0023: create_event( access=001f0003, attributes=00000080, manual_reset=1,
initial_state=0, objattr={rootdir=0014,sd={control=00000004,owner=<not
present>,group=<not
present>,sacl={},dacl={{AceType=ACCESS_ALLOWED_ACE_TYPE,Mask=e01f001f,AceFlags=0,Sid={S-1-5-4}},{AceType=ACCESS_ALLOWED_ACE_TYPE,Mask=e01f001f,AceFlags=0,Sid={S-1-5-4}}}},name=L"Global\\CorDBIPCSetupSyncEvent_36"}
)
0023: create_event() = 0 { handle=01c4 }
...
0025:trace:advapi:GetKernelObjectSecurity
(0xc4,0x00000005,0x14ef40,0x00000050,0x33f7e8)
0025:trace:ntdll:NtQuerySecurityObject
(0xc4,0x00000005,0x14ef40,0x00000050,0x33f7e8)
0025: get_security_object( handle=00c4, security_info=00000005 )
0025: get_security_object() = 0 { sd_len=00000050,
sd={control=00000037,owner={S-1-5-4},group=<not
present>,sacl={},dacl={{AceType=ACCESS_ALLOWED_ACE_TYPE,Mask=e01f001f,AceFlags=0,Sid={S-1-5-4}},{AceType=ACCESS_ALLOWED_ACE_TYPE,Mask=e01f001f,AceFlags=0,Sid={S-1-5-4}}}}
}
0025:trace:ntdll:RtlGetDaclSecurityDescriptor
(0x14ef40,0x33f7c3,0x33f7ec,0x33f7c2)
0025:trace:ntdll:RtlGetAce (0x14ef60,0,0x33f7f0)
0025:trace:ntdll:RtlLengthSid sid=0x14ef54
0025: open_event( access=001f0003, attributes=00000002, rootdir=0034,
name=L"Global\\CorDBIPCLSEventAvailName_36" )
0025: open_event() = 0 { handle=00c8 }
...
--- snip ---
"new" behaviour, where default process token is now like this:
Token owner -> S-1-5-32-544 "BUILTIN\Administrators" (alias)
Token user -> S-1-5-4 "NT AUTHORITY\INTERACTIVE" (well-known group)
Token primary group -> S-1-5-32-544 "BUILTIN\Administrators" (alias)
--- snip ---
...
0024:trace:ntdll:NtOpenProcessTokenEx (0x1b0,0x00000008,0x00000000,0x318e6d0)
0024: open_token( handle=01b0, access=00000008, attributes=00000000,
flags=00000000 )
0024: open_token() = 0 { token=01b4 }
...
0024:trace:advapi:GetTokenInformation (0x1b4, TokenOwner, 0x184130, 20,
0x318e6e0):
0024:trace:ntdll:NtQueryInformationToken (0x1b4,4,0x184130,20,0x318e6e0)
0024: get_token_sid( handle=01b4, which_sid=00000004 )
0024: get_token_sid() = 0 { sid_len=16, sid={S-1-5-32-544} }
...
0024: create_event( access=001f0003, attributes=00000080, manual_reset=1,
initial_state=0, objattr={rootdir=0018,sd={control=00000004,owner=<not
present>,group=<not
present>,sacl={},dacl={{AceType=ACCESS_ALLOWED_ACE_TYPE,Mask=e01f001f,AceFlags=0,Sid={S-1-5-32-544}},{AceType=ACCESS_ALLOWED_ACE_TYPE,Mask=e01f001f,AceFlags=0,Sid={S-1-5-32-544}}}},name=L"Global\\CorDBIPCSetupSyncEvent_37"}
)
0024: create_event() = 0 { handle=01c8 }
...
0026:trace:advapi:GetKernelObjectSecurity
(0xc8,0x00000005,(nil),0x00000000,0x33f7e8)
0026:trace:ntdll:NtQuerySecurityObject
(0xc8,0x00000005,(nil),0x00000000,0x33f7e8)
0026: get_security_object( handle=00c8, security_info=00000005 )
0026: get_security_object() = 0 { sd_len=00000058,
sd={control=00000037,owner={S-1-5-4},group=<not
present>,sacl={},dacl={{AceType=ACCESS_ALLOWED_ACE_TYPE,Mask=e01f001f,AceFlags=0,Sid={S-1-5-32-544}},{AceType=ACCESS_ALLOWED_ACE_TYPE,Mask=e01f001f,AceFlags=0,Sid={S-1-5-32-544}}}}
}
...
--- snip ---
Using the "admins" sid (alias) as token user in
server/token.c:token_create_admin() instead of current "interactive" sid fixes
the problem. Though I don't know if this is the right thing to do.
I hope I provided enough infos and let Alexandre handle it ;-)
To get detailed token infos/dumps you might be interested in this little
console app, from cygwin's Corinna Vinschen ;-)
http://www.mail-archive.com/cygwin@cygwin.com/msg71800.html
It might provide useful information when run under different security
principals.
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.