December 2016 - Wine-Bugs - list.winehq.org

[Bug 42055] New: Chessbase 13: Unhandled exception: page fault on execute access to 0x4bda7b50 in 32-bit code (0x4bda7b50).
by wine-bugs＠winehq.org Feb. 12, 2021

Feb. 12, 2021

https://bugs.winehq.org/show_bug.cgi?id=42055 Bug ID: 42055 Summary: Chessbase 13: Unhandled exception: page fault on execute access to 0x4bda7b50 in 32-bit code (0x4bda7b50). Product: Wine Version: 1.8-rc4 Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: twirpxacc91919(a)gmail.com Created attachment 56542 --> https://bugs.winehq.org/attachment.cgi?id=56542 Program Error Details The program gives a pop-up that it encountered a serious problem then says it must shut down. It is very inconvenient and happened more than twenty times. (I am not knowledgeable about any code or programming language, so sorry for my ignorance.) -- 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.

2 6

[Bug 38356] New: Xibo Player 1.7.3: Cant start
by wine-bugs＠winehq.org Feb. 12, 2021

Feb. 12, 2021

https://bugs.winehq.org/show_bug.cgi?id=38356 Bug ID: 38356 Summary: Xibo Player 1.7.3: Cant start Product: Wine Version: 1.7.40 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mscoree Assignee: wine-bugs(a)winehq.org Reporter: ignacio.santolin(a)gmail.com Distribution: --- Created attachment 51200 --> https://bugs.winehq.org/attachment.cgi?id=51200 Xibo debug I Installed http://xibo.org.uk/get-xibo/ "Xibo For Windows" And When i tries to start, shows the attached debug and cant start -- 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.

2 7

[Bug 41728] New: While using the app it keeps crashing and operation is very slow.
by wine-bugs＠winehq.org Feb. 12, 2021

Feb. 12, 2021

https://bugs.winehq.org/show_bug.cgi?id=41728 Bug ID: 41728 Summary: While using the app it keeps crashing and operation is very slow. Product: Wine Version: unspecified Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ryanscik5(a)hotmail.com Created attachment 56165 --> https://bugs.winehq.org/attachment.cgi?id=56165 yugioh pro I am using yugioh pro on wine and I never had problems. 2 days ago the app became very slow and it crashes when playing. I have no idea what's wrong. I tried installing a new version but still the same problems. -- 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.

2 6

[Bug 36633] New: Administrative privileges not sufficient
by wine-bugs＠winehq.org Feb. 12, 2021

Feb. 12, 2021

http://bugs.winehq.org/show_bug.cgi?id=36633 Bug ID: 36633 Summary: Administrative privileges not sufficient Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: 9728889999o(a)gmail.com Created attachment 48676 --> http://bugs.winehq.org/attachment.cgi?id=48676 Error Message I tried to run an application under Wine and it says that I have "insufficient privileges, please close and run again as administrator." I tried to run the Windows 7 USB/DVD Creator. See the attachment for more. -- 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.

2 10

[Bug 39306] New: wine crash when using Lord of the rings : battle for middle earth 2
by wine-bugs＠winehq.org Feb. 12, 2021

Feb. 12, 2021

https://bugs.winehq.org/show_bug.cgi?id=39306 Bug ID: 39306 Summary: wine crash when using Lord of the rings : battle for middle earth 2 Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3dx9 Assignee: wine-bugs(a)winehq.org Reporter: titouan.dugre(a)gmail.com Distribution: --- Wine gives this message : "direct 3 D error 0*80004001 (E_NOTIMPL) 14 adresses : (0):(unknow mind) (unknow) (0):(unknow mind) (unknow) (0):(unknow mind) (unknow) (0):(unknow mind) (unknow) (0):(unknow mind) (unknow) (0):(unknow mind) (unknow) (0):(unknow mind) (unknow) (0):(unknow mind) (unknow) (0):(unknow mind) (unknow) (0):(unknow mind) (unknow) (0):(unknow mind) (unknow) (0):(unknow mind) (unknow) (0):(unknow mind) (unknow) (0):(unknow mind) (unknow) -- 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.

2 12

[Bug 37067] New: System.NotSupportedException: CodePage 1361 not supported
by wine-bugs＠winehq.org Feb. 12, 2021

Feb. 12, 2021

http://bugs.winehq.org/show_bug.cgi?id=37067 Bug ID: 37067 Summary: System.NotSupportedException: CodePage 1361 not supported Product: Wine Version: 1.7.22 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mscoree Assignee: wine-bugs(a)winehq.org Reporter: t_arceri(a)yahoo.com.au Gemini Script Editor crashes when trying to open a script. With the following exception thrown. The scripts are from rpgmaker I think it might use Korean as a was to try obfuscate the script Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for ScintillaNet.Scintilla ---> System.NotSupportedException: CodePage 1361 not supported at System.Text.Encoding.GetEncoding (Int32 codepage) [0x00000] in <filename unknown>:0 -- 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.

2 6

[Bug 35927] New: Win Toolkit v.1.4.37.20 requires administrative privilegies on startup.
by wine-bugs＠winehq.org Feb. 12, 2021

Feb. 12, 2021

http://bugs.winehq.org/show_bug.cgi?id=35927 Bug ID: 35927 Summary: Win Toolkit v.1.4.37.20 requires administrative privilegies on startup. Product: Wine Version: 1.6.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: sov.info(a)mail.ru Created attachment 47977 --> http://bugs.winehq.org/attachment.cgi?id=47977 screenshot I tried to login as root and run wine, but this error still present. You can see it on screenshot... Ubuntu 14.04 beta x64, wine x86-x64, ver. 1.6.2 from proposed. -- 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.

2 7

[Bug 36434] New: Regression: Capture NX-D fails with "Initialization error (E010)"
by wine-bugs＠winehq.org Feb. 12, 2021

Feb. 12, 2021

http://bugs.winehq.org/show_bug.cgi?id=36434 Bug ID: 36434 Summary: Regression: Capture NX-D fails with "Initialization error (E010)" Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: fordfrog(a)fordfrog.com i'm using latest wine from source repository. this bug is probably week or so old. when launching Nikon Capture NX-D, it fails with "Initialization error (E010)". i have wine compiled with both 32bit and 64 versions (using gentoo live ebuild), but for the app i am using 32 bit version (64bit version does not work due to some missing implementation in wine). i'm running the app using following command: WINEPREFIX=~/.wine32 WINEARCH=win32 wine .wine32/drive_c/Program\ Files/Nikon/Capture\ NX-D/Module/CaptureNX-D.exe .wine32 directory is initialized for 32bit arch and windows 8. before week or so the app started without any issue and it was usable. but few days ago it stopped to launch. this is the output before the bug occurs: $ WINEPREFIX=~/.wine32 WINEARCH=win32 wine .wine32/drive_c/Program\ Files/Nikon/Capture\ NX-D/Module/CaptureNX-D.exe fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x33fbcc 1 C) semi-stub fixme:heap:HeapSetInformation (nil) 1 (nil) 0 fixme:thread:GetThreadPreferredUILanguages 52, 0x33f9c0, 0x33fa30 0x33f9c8 fixme:heap:HeapSetInformation (nil) 1 (nil) 0 fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x33edc0 1 C) semi-stub fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x33ee50 1 C) semi-stub fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0x33ec80 1 C) semi-stub fixme:msvcrt:__clean_type_info_names_internal (0x788b0e54) stub fixme:msvcrt:__clean_type_info_names_internal (0x1001e33c) stub fixme:thread:SetThreadIdealProcessor (0xfffffffe): stub the complete process of installation and running is the same as in bug #35864. -- 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.

2 7

[Bug 39996] New: Application Autodata will not load icons and text
by wine-bugs＠winehq.org Feb. 12, 2021

Feb. 12, 2021

https://bugs.winehq.org/show_bug.cgi?id=39996 Bug ID: 39996 Summary: Application Autodata will not load icons and text Product: Wine Version: 1.7.54 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: tutonis(a)gmail.com Distribution: --- Created attachment 53438 --> https://bugs.winehq.org/attachment.cgi?id=53438 It works with wine 1.7.53 After loading application all icons are not show until clicked or focused by keyboard arrow movements. As you can see by pictures there is upper and lower icon regions. After clicking place where icon suppose to be the icon is revealed. The upper icon region gets different icons depending what is being selected. Icons are not redrawn after "revealing" them with mouse or keyboard and changing selection (icons should be redawrn and updated by selected option). The issue is nor present in wine 1.7.53 but happens in 1.7.54 with same configurations. -- 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.

2 7

[Bug 14697] New: wineserver: debug events can block completion of queued user APCs
by wine-bugs＠winehq.org Feb. 11, 2021

Feb. 11, 2021

http://bugs.winehq.org/show_bug.cgi?id=14697 Summary: wineserver: debug events can block completion of queued user APCs Product: Wine Version: CVS/GIT Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, consider the following scenario... A debugger is attached to a debuggee. The debuggee has two threads. The debugger processes debug events and queries virtual memory info of remote process using VirtualQueryEx in its main loop. VirtualQueryEx -> NtQueryVirtualMemory -> enqueues APC_VIRTUAL_QUERY user APC for remote process (debuggee). The calling thread is blocked until the APC is completed. Following is the "good" case: tid=0009 (debugger process, calling thread, main debugger loop) tid=001a (debuggee thread 1) --- snip --- .. 0009: queue_apc( thread=(nil), process=0x54, call={APC_VIRTUAL_QUERY,addr=0x7fff0000} ) 001a: *wakeup* signaled=192 cookie=0x7ffdb7b4 0009: queue_apc() = 0 { handle=0x68, self=0 } 0009: select( flags=4, cookie=0x32d30c, signal=(nil), prev_apc=(nil), timeout=infinite, result={}, handles={0x68} ) 0009: select() = PENDING { apc_handle=(nil), timeout=infinite, call={APC_NONE} } 001a: select( flags=4, cookie=0x7ffdb7b4, signal=(nil), prev_apc=(nil), timeout=1c8f097946d2824 (-0.1787600), result={}, handles={} ) 001a: select() = USER_APC { apc_handle=0x68, timeout=1c8f097946d2824 (-0.1787600), call={APC_VIRTUAL_QUERY,addr=0x7fff0000} } 001a: select( flags=4, cookie=0x7ffdb7b4, signal=(nil), prev_apc=0x68, timeout=1c8f097946d2824 (-0.1792110), result={APC_VIRTUAL_QUERY,status=40000002,base=(nil),alloc_base=(nil),size=0,state=0,prot=0,alloc_prot=0,alloc_type=0}, handles={} ) 0009: *wakeup* signaled=0 cookie=0x32d30c 001a: select() = PENDING { apc_handle=(nil), timeout=1c8f097946d2824 (-0.1792110), call={APC_NONE} } 0009: get_apc_result( handle=0x68 ) 0009: get_apc_result() = 0 { result={APC_VIRTUAL_QUERY,status=40000002,base=(nil),alloc_base=(nil),size=0,state=0,prot=0,alloc_prot=0,alloc_type=0} } --- snip --- Now the interesting one, which ultimately leads to block of calling thread ... tid=0009 (debugger process, calling thread, main debugger loop) tid=001a (debuggee thread 1) tid=001b (debuggee thread 2) --- snip --- 0009: continue_debug_event( pid=0019, tid=001a, status=65538 ) 001a: *wakeup* signaled=258 cookie=0x7ffdb7b4 001b: *wakeup* signaled=258 cookie=0x7ffd77b4 0009: continue_debug_event() = 0 .. 0009: read_process_memory( handle=0x54, addr=0x7ffd8000 ) 001a: *signal* signal=19 0009: read_process_memory() = 0 { data= {} } 0009: read_process_memory( handle=0x54, addr=0x7ffd4000 ) 001a: *signal* signal=19 0009: read_process_memory() = 0 { data={} } 0009: queue_apc( thread=(nil), process=0x54, call={APC_VIRTUAL_QUERY,addr=(nil)} ) 001b: *wakeup* signaled=192 cookie=0x7ed44874 0009: queue_apc() = 0 { handle=0x68, self=0 } 001a: load_dll( handle=(nil), base=0x61090000, size=102400, dbg_offset=0, dbg_size=0, name=0x13e468, filename=L"C:\\windows\\system32\\msacm32.dll" ) 001a: *sent signal* signal=10 001b: *sent signal* signal=10 001a: load_dll() = 0 .. 0009: select( flags=4, cookie=0x32d30c, signal=(nil), prev_apc=(nil), timeout=infinite, result={}, handles={0x68} ) 0009: select() = PENDING { apc_handle=(nil), timeout=infinite, call={APC_NONE} } 001a: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context= {...}) 001a: set_thread_context() = 0 { self=1 } 001b: select( flags=4, cookie=0x7ed44874, signal=(nil), prev_apc=(nil), timeout=infinite, result={}, handles={0x4c} ) 001b: select() = USER_APC { apc_handle=0x68, timeout=infinite, call={APC_VIRTUAL_QUERY,addr=(nil)} } 001a: select( flags=4, cookie=0x7ffdb7b4, signal=(nil), prev_apc=(nil), timeout=0, result={}, handles={} ) 001a: select() = PENDING { apc_handle=(nil), timeout=1c8f09794c8b694 (+0.0000000), call={APC_NONE} } 001b: set_thread_context( handle=0xfffffffe, flags=00010007, suspend=1, context= {...}) 001b: set_thread_context() = 0 { self=1 } 001b: select( flags=4, cookie=0x7ffd77b4, signal=(nil), prev_apc=(nil), timeout=0, result={}, handles={} ) 001b: select() = PENDING { apc_handle=(nil), timeout=1c8f09794c90dc4 (+0.0000000), call={APC_NONE} } ... --- snip --- At this point, tid=0009 (debugger) is blocked forever. When the APC_VIRTUAL_QUERY user APC is queued, remote thread 001b is selected/destined to carry out the APC. After thread 001a and 001b woke up, a dynamic library is loaded from thread 001a which results in LOAD_DLL_DEBUG_EVENT dispatched. This initiates the suspension of all threads in the child process (SIGUSR1 is sent for 001a and 001b). Thread 001a is suspended first, 001b next. The suspension of 001b happens to a time when 001b is about to carry out the APC_VIRTUAL_QUERY. Meanwhile thread 0009 (calling process) is waiting for APC completion result forever because it's blocked by VirtualQueryEx in debugger loop, unable to receive and process any debug event. 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.

2 21