https://bugs.winehq.org/show_bug.cgi?id=45039
Bug ID: 45039
Summary: Mono: System.UnauthorizedAccessException when trying
to read from stdin when both stdout and stderr are
redirected
Product: Wine
Version: 3.6
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: mk+winehq1803(a)pimpmybyte.de
Distribution: ---
I wrote a simple C# program that reads a line from stdin and prints it in
uppercase (01_shout.cs in [1]).
The exe (compiled on Ubuntu with "mcs") is available for download at
http://l.proggr.de/?1839m7ier
It accepts interactive input when run in cmd.exe on windows 7, even with both
stdout and stderr redirected (02_log_win7.txt in [1]).
In Ubuntu, it crashes when trying to read the line while stdin is a TTY and
both stdout and stderr are redirected (03_log_wine.txt in [1]).
Ubuntu 14.04.5 LTS trusty, wine-3.6,
Mono JIT compiler version 3.2.8 (Debian 3.2.8+dfsg-4ubuntu1.1)
Kernel 3.13.0-142-generic #191-Ubuntu SMP Fri Feb 2 12:14:37 UTC 2018 i686 i686
i686 GNU/Linux
[1] https://gist.github.com/mk-pmb/adae211e875ff11274d9b81248d033a3
--
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=37644
Bug ID: 37644
Summary: .NET 3.5 crash when running System.Console.Clear()
Product: Wine
Version: 1.7.30
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: james(a)jameswarner.us
Distribution: ---
Created attachment 50099
--> https://bugs.winehq.org/attachment.cgi?id=50099
Example program, source code to said program and output log
When running System.Console.Clear() under .NET 3.5 in WINE (installed in a
clean .wine through Winetricks), it will crash with:
Unhandled Exception: System.IO.IOException: Invalid handle.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.Console.GetBufferInfo(Boolean throwOnNoConsole, Boolean&
succeeded)
at System.Console.Clear()
This can be reproduced by running System.Console.Clear() under any application
in .NET 3.5.
Attached is a demo application to reproduce this, the source code to produce
this issue and the log generated.
WINE version: 1.7.30 under Debian (sid) x86.
--
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=23015
Summary: PL\SQL Developer: shows standard message boxes behind
main window
Product: Wine
Version: 1.2-rc2
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: comdlg32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: chaostya(a)gmail.com
When I write a query in PL\SQL Developer window, then issue it against DB and
then want to close the window I click [x] and it looks like nothing happens,
but if I move main window down I would see a standard "question" message dialog
box asking me if I want to save my changes. I'm on 1.2-rc2 and it's a
regression from 1.2-rc1
--
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=44840
Bug ID: 44840
Summary: Icewind Dale unusably glitchy starting with Wine
Version 3.2
Product: Wine
Version: 3.4
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: wodencafe(a)gmail.com
Distribution: ---
Starting with Wine 3.2 and on, Icewind Dale (2.0.0.11 (GOG)) is having very
strange input / glitchy rendering issues.
I have attached a video comparison with 3.1 where it works fine.
Tested with 3.2, 3.3, and 3.4, and all have the strange input and glitchy
problem.
There are no additional wine modifications.
Please see the video for example of problem, and comparison of when it was
working with 3.1
--
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=44821
Bug ID: 44821
Summary: Gothic 1 inventory objects not rendered
Product: Wine
Version: 3.4
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: trivial
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: w1t3sc4(a)cybergal.com
Distribution: ---
Created attachment 60854
--> https://bugs.winehq.org/attachment.cgi?id=60854
Inventory objects are not rendered.
Object icons in the inventory are not rendered (screenshot).
This bug was absent in Wine 3.1, but appears in Wine 3.3 and 3.4.
--
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.
https://bugs.winehq.org/show_bug.cgi?id=45000
Bug ID: 45000
Summary: Ziphead by CNCD & Fairlight fails with
GL_OUT_OF_MEMORY
Product: Wine
Version: 3.6
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: directx-d3d
Assignee: wine-bugs(a)winehq.org
Reporter: arabek+wine(a)gmail.com
Distribution: ---
Created attachment 61129
--> https://bugs.winehq.org/attachment.cgi?id=61129
wine-staging ziphead.log (gzipped)
A demoscene demo from 2015 fails to show any kind of output.
I'm attaching the log.
Expected result: running as under native Windows.
Wine version: 3.6 & 3.6-staging (basically the same output, attached is the log
from staging).
--
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=44899
Bug ID: 44899
Summary: Access violation at address 000406686 read of address
FFFFFFFFFE8
Product: Wine
Version: 3.2
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: stevedonato(a)gmail.com
Distribution: ---
Created attachment 60979
--> https://bugs.winehq.org/attachment.cgi?id=60979
the Program exe
attempte to install (PowerISO7-x64.exe) when I got;
"Access violation at address 000406686 read of address FFFFFFFFFE8" and no
trace dump
using wine version 3.2
--
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=45533
Bug ID: 45533
Summary: Puyo Puyo Tetris (Steam) - Game crashes on startup
Product: Wine
Version: 3.13
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: sirmentio123(a)gmail.com
Distribution: ---
Created attachment 61934
--> https://bugs.winehq.org/attachment.cgi?id=61934
These logs are made from the moment I launch steam through the wine prefix to
when the application crashes and when I close it/steam itself out
The program crashes upon launch in the Steam version. win64 was required in
order to play. This was tested obviously with the Steam version and I'm not
sure if it's the same for the one from the SEGA store. As far as I know.
Using the staging version of 3.13
Ubuntu 18.04 x86 64
Nvidia driver 390
X.Org X Server 1.19.6
--
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=46568
Bug ID: 46568
Summary: 64-bit msxml6.dll from Microsoft Core XML Services 6.0
redist package fails to load (Wine doesn't respect
44-bit user-mode VA limitation from Windows < 8.1)
Product: Wine
Version: 4.0
Hardware: x86-64
URL: https://download.microsoft.com/download/2/e/0/2e01308a
-e17f-4bf9-bf48-161356cf9c81/msxml6_x64.msi
OS: Linux
Status: NEW
Keywords: download, win64
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: focht(a)gmx.net
Distribution: ---
Hello folks,
reported by Louis in https://bugs.winehq.org/show_bug.cgi?id=46107#c2
--- quote ---
I tried winetricks msxml3 and msxml6, but somehow it didn`t work out in 64-bit
wineprefix; i get errors that msxml is not registered etc,
Does anyone know a workaround to use native msxml on 64-bit prefix?
--- quote ---
Relevant part of trace log:
--- snip ---
$ pwd
/home/focht/.wine/drive_c/Program Files/Altium/AD18
$ WINEDEBUG=+seh,+relay,+loaddll,+virtual wine64 ./X2.EXE >>log.txt 2>&1
...
002a:Call KERNEL32.LoadLibraryExW(0053f2b0
L"C:\\windows\\system32\\msxml6.dll",00000000,00000008) ret=7fbe435d7558
...
002a:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\msxml6.dll"
at 0x7ff79e00000: native
002a:Call PE DLL (proc=0x7ff79e0101c,module=0x7ff79e00000
L"msxml6.dll",reason=PROCESS_ATTACH,res=(nil))
...
002a:Call KERNEL32.HeapCreate(00000001,00000000,00000000) ret=7ff79e18411
002a:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00110000
2000 00000004
002a:trace:virtual:map_view got mem with anon mmap
0x7fbe39819000-0x7fbe39929000
002a:trace:virtual:VIRTUAL_DumpView View: 0x7fbe39820000 - 0x7fbe3992ffff
(valloc)
002a:trace:virtual:VIRTUAL_DumpView 0x7fbe39820000 - 0x7fbe3992ffff --rw-
002a:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff 0x7fbe39820000
00010000 1000 00000004
002a:trace:virtual:mprotect_exec forcing exec permission on
0x7fbe39820000-0x7fbe3982ffff
002a:trace:virtual:VIRTUAL_DumpView View: 0x7fbe39820000 - 0x7fbe3992ffff
(valloc)
002a:trace:virtual:VIRTUAL_DumpView 0x7fbe39820000 - 0x7fbe3982ffff c-rw-
002a:trace:virtual:VIRTUAL_DumpView 0x7fbe39830000 - 0x7fbe3992ffff --rw-
002a:Ret KERNEL32.HeapCreate() retval=7fbe39820000 ret=7ff79e18411
...
002a:Call ntdll.RtlAllocateHeap(7fbe39820000,00000000,00000060) ret=7ff79e03c10
002a:Ret ntdll.RtlAllocateHeap() retval=7fbe39822730 ret=7ff79e03c10
002a:Call msvcrt.memset(7fbe39822740,00000000,00000042) ret=7ff79e03a5a
002a:Ret msvcrt.memset() retval=7fbe39822740 ret=7ff79e03a5a
002a:trace:seh:NtRaiseException code=c0000005 flags=0 addr=0x7ff79e03efe
ip=7ff79e03efe tid=002a
002a:trace:seh:NtRaiseException info[0]=0000000000000000
002a:trace:seh:NtRaiseException info[1]=ffffffffffffffff
002a:trace:seh:NtRaiseException rax=000000000011b2d0 rbx=6c61567274736270
rcx=0000000000000008 rdx=0000000000000000
002a:trace:seh:NtRaiseException rsi=0000000000007fbe rdi=0000000000000730
rbp=00000ff7c73044e8 rsp=000000000053ea70
002a:trace:seh:NtRaiseException r8=00007fbe39822740 r9=0000000000000000
r10=0000000000000000 r11=0000000000000000
002a:trace:seh:NtRaiseException r12=00007fbe39822740 r13=000007ff79f8dc80
r14=00007fbe436c6160 r15=000000000053f708
...
002a:exception c0000005 in PE entry point
(proc=0x7ff79e0101c,module=0x7ff79e00000,reason=PROCESS_ATTACH,res=(nil))
002a:Ret PE DLL (proc=0x7ff79e0101c,module=0x7ff79e00000
L"msxml6.dll",reason=PROCESS_ATTACH,res=(nil)) retval=0
002a:Call PE DLL (proc=0x7ff79e0101c,module=0x7ff79e00000
L"msxml6.dll",reason=PROCESS_DETACH,res=(nil))
002a:Ret PE DLL (proc=0x7ff79e0101c,module=0x7ff79e00000
L"msxml6.dll",reason=PROCESS_DETACH,res=(nil)) retval=1
002a:trace:loaddll:free_modref Unloaded module
L"C:\\windows\\system32\\msxml6.dll" : native
002a:Ret KERNEL32.LoadLibraryExW() retval=00000000 ret=7fbe435d7558
002a:err:ole:COMPOBJ_DllList_Add couldn't load in-process dll
L"C:\\windows\\system32\\msxml6.dll"
--- snip ---
It seems that certain older 64-bit components such as Microsoft XML libs make
assumptions about the 64-bit user-mode virtual address space layout.
This is different from the usual broken apps a la "I failed at porting my
32-bit app to 64-bit" (pointer truncation).
In this case, pointers from certain allocations are broken into multiple parts
and used as indices into multi-level lookup tables.
Pitfall: there is a 44-bit user-mode VA limitation (8TB) for 64-bit Windows
which was lifted starting with Windows 8.1+.
Wine doesn't respect the 44-bit pre-Windows 8.1 virtual address space limits,
allowing process heaps to be placed in 0000'7Fxx'0000'0000 range (128 TB) which
causes out-of-bounds access to lookup tables when indices overflow (derived
from pointer bits). The exception occurs in entry point, causing 'msxml6.dll'
to be unloaded.
One workaround is to move Wine's top-down allocations/heaps into 8 TB VA range
(Wine preloader) and impose same user-mode address space bits limits as with
all 64-bit Windows versions < 8.1 to stay "compatible". I've tested it and it
works for native here. Not sure if it's worth to change though.
I don't know if a separate 64-bit MSXML6 re-distributable package exists that
has been fixed wrt Windows 8.1+ address space limits.
MSXML6 is part of Windows OS for newer versions and automatically kept
up-to-date.
$ sha1sum msxml6_x64.msi
1eb84eeae7729ea5db7fe79779f4e216114261ba msxml6_x64.msi
$ du -sh msxml6_x64.msi
2.6M msxml6_x64.msi
$ wine --version
wine-4.0-276-g84459ba94b
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.