wine-bugs July 2011

wine-bugs@winehq.org

1 participants
9286 discussions

[Bug 16544] New: winmm: mixerOpen(): when CALLBACK_WINDOW flag given, NULL Callback is also valid
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=16544 Summary: winmm: mixerOpen(): when CALLBACK_WINDOW flag given, NULL Callback is also valid Product: Wine Version: 1.1.10 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winmm&mci AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, while revisiting a Battlefield 2 issue I came across another one... BF2 voice setup (C:\Program Files\EA GAMES\Battlefield 2\BF2VoiceSetup.exe) crashes when "Save Settings" button is clicked. This happens from BF2 sub-installer (causing no harm) or when the voice setup app is run stand alone. --- snip --- .. wine: Unhandled page fault on read access to 0x0000002c at address 0x408661 (thread 0044), starting debugger... Unhandled exception: page fault on read access to 0x0000002c in 32-bit code (0x00408661). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:00408661 ESP:0033dadc EBP:0033dbc0 EFLAGS:00010216( - 00 -RIAP1) EAX:00000000 EBX:00000111 ECX:00000000 EDX:00000002 ESI:0033dadc EDI:0033dbc0 Stack dump: 0x0033dadc: 00000001 0033f60c 00000111 cccccccc 0x0033daec: cccccccc cccccccc cccccccc cccccccc 0x0033dafc: cccccccc cccccccc cccccccc cccccccc 0x0033db0c: cccccccc cccccccc cccccccc cccccccc 0x0033db1c: cccccccc cccccccc cccccccc cccccccc 0x0033db2c: cccccccc cccccccc cccccccc cccccccc Backtrace: =>0 0x00408661 in bf2voicesetup (+0x8661) (0x0033dbc0) 1 0x00403978 in bf2voicesetup (+0x3978) (0x0033dd8c) 2 0x7c171915 in mfc71 (+0x31915) (0x0033ddbc) 3 0x7c14db36 in mfc71 (+0xdb36) (0x0033dde0) 4 0x7c175cd8 in mfc71 (+0x35cd8) (0x0033de30) 5 0x7c175cf2 in mfc71 (+0x35cf2) (0x0033dec4) .. --- snip --- The crash location is only indirectly related to the problem, hence this was a bit tricky to debug to the real cause. The real problem seems to be a Wine's winmm.mixerOpen() handling fdwOpen flags with CALLBACK_WINDOW when dwCallback is NULL. Consider the following (WINEDEBUG=+winmm): --- snip --- 0023:trace:winmm:DllMain 0x60380000 0x1 0x1 0023:trace:winmm:MMDRV_Init () .. 0023:trace:winmm:MIXER_Open (0x425f0c, 0, 00000000, 00000000, 00010000) .. --- snip --- mixerOpen() with CALLBACK_WINDOW flags and NULL dwCallback results in MMSYSERR_INVALPARAM. Corresponding Wine code: --- snip dlls/winmm/winmm.c:MIXER_Open --- UINT MIXER_Open(LPHMIXER lphMix, UINT uDeviceID, DWORD_PTR dwCallback, DWORD_PTR dwInstance, DWORD fdwOpen, BOOL bFrom32) { ... switch (fdwOpen & CALLBACK_TYPEMASK) { .. case CALLBACK_WINDOW: mod.dwInstance = dwCallback; if (!IsWindow((HWND)dwCallback)) return MMSYSERR_INVALPARAM; break; } .. } --- snip dlls/winmm/winmm.c:MIXER_Open --- MSDN: http://msdn.microsoft.com/en-us/library/ms712134.aspx It says: "The dwCallback parameter is assumed to be a window handle (HWND)." Unfortunately the app expects MMSYSERR_NOERROR but not a failure (bad app error handling anyway). Hence crucial data structures are not getting setup properly (C++ instances/member data), leading to NULL ptr dereference at much later time. A small conformance test case (fdwOpen=CALLBACK_WINDOW, dwCallback=NULL) should reveal this MSDN documentation insufficiency. 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.

1 5

[Bug 16598] New: winuser.rh misses some standard control ids (dialog button, ...) resulting in wrc failure with windows.h include only
by wine-bugs＠winehq.org 12 Oct '11

12 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=16598 Summary: winuser.rh misses some standard control ids (dialog button, ...) resulting in wrc failure with windows.h include only Product: Wine Version: 1.1.10 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, while doing some occasional end user support on #winehq (*yuck*), one user complained about wrc not compiling his .rc file. Visual C++ and mingw toolchains compiled it in Windows without problems but Wine's wrc didn't like it. --- snip --- ... resource.rc:114:31: Error: syntax error --- snip --- He sent me a link to the .rc file to have a look at. Relevant parts: Resource.rc: --- snip --- // Microsoft Visual C++ generated resource script. // #include "resource.h" #define APSTUDIO_READONLY_SYMBOLS ///////////////////////////////////////////////////////////////////////////// // // Generated from the TEXTINCLUDE 2 resource. // #include <windows.h> ///////////////////////////////////////////////////////////////////////////// #undef APSTUDIO_READONLY_SYMBOLS ... ///////////////////////////////////////////////////////////////////////////// // // Menu // IDR_MENU MENU BEGIN ... END ///////////////////////////////////////////////////////////////////////////// // // Dialog // IDD_MEMTRANSFER DIALOGEX 100, 100, 174, 90 STYLE DS_SETFONT | DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU CAPTION "Memory Transfer" FONT 8, "Courier New", 0, 0, 0x0 BEGIN DEFPUSHBUTTON "&OK",IDOK,42,72,40,14 ... --- snip --- Resource.h: --- snip --- //{{NO_DEPENDENCIES}} // Microsoft Visual C++ generated include file. // Used by resource.rc // #define IDR_MENU 100 #define IDI_ICON 101 #define IDB_BITMAP 102 #define IDR_MAIN_ACCEL 103 #define IDD_MEMTRANSFER 104 ... --- snip --- The resource include chain is as follows: resource.h windows.h (due to RC_INVOKED defined by wrc) -> winresrc.h -> winuser.rh and commctrl.rh The problem is that winuser.rh defines only a subset of winuser.h control ids This breaks resource scripts which for example reference standard dialog button IDs. Telling the user to explicitly include <winuser.h> solved his problems. You might want to extend winuser.rh a bit to include often used standard control ids (ex: dialog button). 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.

1 4

[Bug 13399] New: Appdb doesn't remember logins
by wine-bugs＠winehq.org 11 Oct '11

11 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=13399 Summary: Appdb doesn't remember logins Product: WineHQ Apps Database Version: unspecified Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: appdb-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: tehblunderbuss(a)gmail.com The appdb doesn't remember logins, like how the bugzilla or wiki do. -- 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.

1 7

[Bug 12939] New: >=wine-0.9.59: Selection using control key and mouse button does not work.
by wine-bugs＠winehq.org 11 Oct '11

11 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=12939 Summary: >=wine-0.9.59: Selection using control key and mouse button does not work. Product: WineHQ Bugzilla Version: unspecified Platform: PC URL: http://www.foobar2000.org OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: bugzilla-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: h.judt(a)gmx.at In Foobar2000, <Control>-<Mouse1> should select or deselect a single entry in the playlist. Instead, it just selects a new entry and deselects all others as if the control key has not been pressed. This worked in <wine-0.9.59 but does not in >=wine-0.9.59 (last version tested was 0.9.61). Similar problem with <Shift>-<Mouse1> existed in =wine-0.9.59, but was solved in >=0.9.60 and works fine now. Occurs with: Foobar2000-0.9.4.4, Exact Audio Copy-0.99prebeta4, file selector dialogs, but might effect other software / versions / dialogs as well. When I launch Foobar2000 and try to add files, I get the following messages on the terminal, maybe this is of some help: fixme:menu:TrackPopupMenuEx not fully implemented fixme:commdlg:GetFileName95 Flags 0x00800000 not yet implemented fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000011 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000041 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000010 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000011 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000011 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000041 fixme:shell:ShellView_OnNotify LVN_KEYDOWN key=0x00000010 -- 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.

1 29

[Bug 21777] New: CreateMutexExA(): use heap for A to W conversion to work around transbase db engine app bug (affects multiple apps, TecDoc CATALOG ...)
by wine-bugs＠winehq.org 11 Oct '11

11 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=21777 Summary: CreateMutexExA(): use heap for A to W conversion to work around transbase db engine app bug (affects multiple apps, TecDoc CATALOG ...) Product: Wine Version: 1.1.39 Platform: x86 URL: http://www.tecdoc.de OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, at the end of TecDoc CATALOG 1/2010 DVD install a crash dialog is displayed while starting a service (the msi part of install is finished anyway). The database engine service has auto-start type set hence on every program start (wine notepad) the infamous crash dialog is displayed. This turns out to be an app bug but due to differences in Wine vs. Windows API design/usage this bug has no consequences in Windows and goes on unnoticed. Unfortunately the part of software that crashes comes from another software supplier "Transaction Software" (http://www1.transaction.de/transaction/). Many automotive spare parts catalogue software (BMW, VW, Audi, GM, Fiat ...) internally use the Transbase SQL database engine for years. In case of Wine/Linux this means many broken apps/versions in the wild due to this bug and even if the original software supplier fixes the bug, it will take years until spare parts catalogue software vendors using the engine to pick up and release new versions of their own products. Despite being an app bug I suggest to modify Wine to work around this developer stupidity. Here it goes, first the crash itself: --- snip --- wine: Unhandled page fault on read access to 0x012f0000 at address 0x681ee546 (thread 001d), starting debugger... Unhandled exception: page fault on read access to 0x012f0000 in 32-bit code (0x681ee546). ... Threads: process tid prio (all id:s are in hex) ... 00000019 (D) C:\TECDOC_CD\1_2010\db\tbmux32.exe 0000001d 0 <== 0000001b 0 0000001a 0 ... Backtrace: =>0 0x681ee546 (0x012eddd4) 1 0x7bc79ac0 NtCreateMutant+0xae(MutantHandle=0x12eded4, access=0x1f0001, attr=0x12edeb4, InitialOwner=0) [/opt/wine/wine-git/dlls/ntdll/sync.c:429] in ntdll (0x012ede94) 2 0x7b869dc8 CreateMutexExW+0xb2(sa=0x12ee16c, name="Global\TBSEM ( TECDOC_C ) = (Key=32769, Ind=0)", flags=0, access=0x1f0001) [/opt/wine/wine-git/dlls/kernel32/sync.c:653] in kernel32 (0x012edee4) 3 0x7b869d0c CreateMutexExA+0xb6(sa=0x12ee16c, name="Global\TBSEM ( TECDOC_C ) = (Key=32769, Ind=0)", flags=0, access=0x1f0001) [/opt/wine/wine-git/dlls/kernel32/sync.c:626] in kernel32 (0x012ee124) 4 0x7b869c08 CreateMutexA+0x3a(sa=0x12ee16c, owner=0, name="Global\TBSEM ( TECDOC_C ) = (Key=32769, Ind=0)") [/opt/wine/wine-git/dlls/kernel32/sync.c:599] in kernel32 (0x012ee144) 5 0x0041a2a3 in tbmux32 (+0x1a2a3) (0x74fd9c13) 6 0x458d28ec (0x83e58955) --- snip --- Starting the whole thing (db service) with +relay exhibits a different behaviour: the service doesn't crash but it doesn't really work, indicating a stack usage problem. Have a close look at security descriptor dump, DACL part: --- snip --- 001e:Call advapi32.InitializeSecurityDescriptor(012ee2bc,00000001) ret=00419b06 001e:Ret advapi32.InitializeSecurityDescriptor() retval=00000001 ret=00419b06 001e:Call advapi32.InitializeAcl(012ede8c,00000400,00000002) ret=00419b28 001e:Ret advapi32.InitializeAcl() retval=00000001 ret=00419b28 001e:Call advapi32.InitializeSid(012eda8c,012eda84,00000001) ret=00419b47 001e:Ret advapi32.InitializeSid() retval=00000001 ret=00419b47 001e:Call advapi32.GetSidSubAuthority(012eda8c,00000000) ret=00419b60 001e:Ret advapi32.GetSidSubAuthority() retval=012eda94 ret=00419b60 001e:Call advapi32.AddAccessAllowedAce(012ede8c,00000002,10000000,012eda8c) ret=00419b7c 001e:Ret advapi32.AddAccessAllowedAce() retval=00000001 ret=00419b7c 001e:Call advapi32.SetSecurityDescriptorDacl(012ee2bc,00000001,012ede8c,00000000) ret=00419b9e 001e:Ret advapi32.SetSecurityDescriptorDacl() retval=00000001 ret=00419b9e 001e:Call KERNEL32.CreateMutexA(012ee2b0,00000000,012ee2d0 "Global\\TBSEM ( TECDOC_C ) = (Key=808607544, Ind=0)") ret=0041a2a3 001e: create_mutex( access=001f0001, attributes=00000080, owned=0, objattr={rootdir=0018,sd={control=00000004,owner=<not present>,group=<not present>,sacl={},dacl={{AceType=unknown<156>,AceFlags=e2},{AceType=unknown<46>,AceFlags=1}}},name=L"Global\\TBSEM ( TECDOC_C ) = (Key=808607544, Ind=0)"} ) 001e: create_mutex() = INVALID_SECURITY_DESCR { handle=0000 } 001e:Ret KERNEL32.CreateMutexA() retval=00000000 ret=0041a2a3 --- snip --- Pretty much messed up. To keep the story short, I translated debugger disassembly snippets and annotated stack dumps into a snippet of C code so you won't get annoyed with too much detail ;-) This is most likely what the app does (might not be 100% accurate, just to illustrate the problem): --- stupid app code start --- static int prepare_sd( SECURITY_ATTRIBUTES *sa) { SID_IDENTIFIER_AUTHORITY sia_world = SECURITY_WORLD_SID_AUTHORITY; BYTE user_sid[0x400]; BYTE acl_buffer[0x400]; int res = InitializeSecurityDescriptor( sa->lpSecurityDescriptor, SECURITY_DESCRIPTOR_REVISION); if( !retval) return res; res = InitializeAcl( (PACL) acl_buffer, sizeof(acl_buffer), ACL_REVISION); if( !retval) return res; res = InitializeSid( (PSID) user_sid, &sia_world, 1); if( !retval) return res; *GetSidSubAuthority( (PSID) user_sid, 0) = SECURITY_WORLD_RID; res = AddAccessAllowedAce( (PACL) acl_buffer, ACL_REVISION, 0x10000000, (PSID) user_sid); if( !retval) return res; return SetSecurityDescriptorDacl( sa->lpSecurityDescriptor, TRUE, (PACL)acl_buffer, FALSE); } static int open_app_mutex( ...) { SECURITY_DESCRIPTOR sd; SECURITY_ATTRIBUTES sa = {0}; char name[0x80]; wsprintfA( name, "xxx", ...); sa.nLength= sizeof(SECURITY_ATTRIBUTES); sa.lpSecurityDescriptor = &sd; sa.bInheritHandle = FALSE; prepare_sd( &sa); CreateMutexA( &sa, FALSE, name); ... } --- stupid app code end --- You can probably spot the biggest mistake of all pretty soon: some "genius" decided to put everything on stack in prepare_sd(). Upon return of prepare_sd() helper function, the stack locals used within prepare_sd() are still *intact* When the app calls CreateMutexA(), the call sequence is as follows: CreateMutexA -> CreateMutexExA -> CreateMutexExW -> NtCreateMutant --- snip dlls/kernel32/sync.c --- HANDLE WINAPI CreateMutexA( SECURITY_ATTRIBUTES *sa, BOOL owner, LPCSTR name ) { return CreateMutexExA( sa, name, owner ? CREATE_MUTEX_INITIAL_OWNER : 0, MUTEX_ALL_ACCESS ); } ... HANDLE WINAPI CreateMutexExA( SECURITY_ATTRIBUTES *sa, LPCSTR name, DWORD flags, DWORD access ) { WCHAR buffer[MAX_PATH]; if (!name) return CreateMutexExW( sa, NULL, flags, access ); if (!MultiByteToWideChar( CP_ACP, 0, name, -1, buffer, MAX_PATH )) { SetLastError( ERROR_FILENAME_EXCED_RANGE ); return 0; } return CreateMutexExW( sa, buffer, flags, access ); } --- snip dlls/kernel32/sync.c --- The problem is buried within CreateMutexExA(): the A to W conversion uses a stack based buffer of MAX_PATH len. This eats stack, partly overwriting the ACL buffer (DACL) from previous prepare_sd() which used to be a stack local too. The reason that this doesn't happen on Windows is most likely conversions are heap based or the call path to kernel mode is very short, not consuming that much stack as Wine does. I verified with a patch to use heap based buffer in CreateMutexExA() for A to W conversion (similar what's being done in CreateMailslotA()) and it lets the app succeed despite that nasty stack bug. I'll leave it to Alexandre to judge this (change or leave Wine as it is). If you decide for WONTFIX (that app bug would really deserve such treatment), I will attach a patch to give users a chance work around various broken transbase versions. 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.

1 4

[Bug 24213] New: WMI: provide "WMIC" stub executable to silence various "file not found" messages (Java SE JRE/JDK installers)
by wine-bugs＠winehq.org 11 Oct '11

11 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=24213 Summary: WMI: provide "WMIC" stub executable to silence various "file not found" messages (Java SE JRE/JDK installers) Product: Wine Version: 1.3.1 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: wmi&wbemprox AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, when installing Java SE JRE/JDK, the installer calls the WMIC executable (using "cmd"), cluttering console with messages: --- snip --- wine: cannot find L"C:\\windows\\system32\\WMIC.exe" --- snip --- This is a tool to access Windows Management Instrumentation (WMI) from the command line, part of WMI core. See: http://msdn.microsoft.com/en-us/library/aa394531.aspx Trace log: --- snip --- 0047:Call KERNEL32.CreateProcessA(00000000,005dead0 "cmd /C WMIC computersystem get model",00000000,00000000,00000001,08000400,00000000,00000000,0074e3f8,0074e43c) ret=6d337ea3 ... 0047:Ret KERNEL32.CreateProcessA() retval=00000001 ret=6d337ea3 ... 0023:Call KERNEL32.CreateProcessW(00000000,0013a9c8 L"WMIC computersystem get model",00000000,00000000,00000001,00000000,00000000,00000000,0033eff0,0033f034) ret=68198ea3 ... wine: cannot find L"C:\\windows\\system32\\WMIC.exe" 0023:Ret KERNEL32.CreateProcessW() retval=00000000 ret=68198ea3 ... 0047:Call KERNEL32.CreateProcessA(00000000,005ef958 "cmd /C WMIC computersystem get manufacturer",00000000,00000000,00000001,08000400,00000000,00000000,0074e3e8,0074e42c) ret=6d337ea3 ... 0047:Call KERNEL32.CreateProcessA(00000000,005ef958 "cmd /C WMIC bios get serialnumber",00000000,00000000,00000001,08000400,00000000,00000000,0074e3e8,0074e42c) ret=6d337ea3 ... 0047:Call KERNEL32.CreateProcessA(00000000,005ef958 "cmd /C WMIC cpu get manufacturer",00000000,00000000,00000001,08000400,00000000,00000000,0074e3f8,0074e43c) ret=6d337ea3 ... --- snip --- Would be fine if Wine could provide a stub executable to silence this until real work on WMI starts one day ... (like Wine's "lodctr" for .NET stuff) Ideally the WMIC stub should print the command line passed to it using own debug channel ;-) 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.

1 6

[Bug 27400] New: SecuROM 4.x/5.x helper driver needs ntoskrnl.exe.IoSetThreadHardErrorMode stub
by wine-bugs＠winehq.org 11 Oct '11

11 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=27400 Summary: SecuROM 4.x/5.x helper driver needs ntoskrnl.exe.IoSetThreadHardErrorMode stub Product: Wine Version: 1.3.21 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ntoskrnl AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, the driver is part of SecuROM 4.x/5.x and dynamically extracted and loaded if "\Device\CdRom0" is present (cdrom0 -> /dev/cdrom via manually created symlink in dosdevices). The driver isn't particularly useful as of now but it shouldn't crash. --- snip --- ... 0021:Call KERNEL32.CreateFileA(0032ce0c "C:\\users\\focht\\Temp\\pfsvgae.sys",40000000,00000000,00000000,00000002,00000000,00000000) ret=00486114 0021:Ret KERNEL32.CreateFileA() retval=00000080 ret=00486114 ... 0021:Call advapi32.CreateServiceA(00161bc8,0032d00c "pfsvgae",0032d00c "pfsvgae",000f01ff,00000001,00000003,00000001,0032ce0c "C:\\users\\focht\\Temp\\pfsvgae.sys",00000000,00000000,00000000,00000000,00000000) ret=00487aae ... fixme:ntoskrnl:IoGetDeviceObjectPointer stub: L"\\Device\\CdRom0" 0 0x53e20c 0x53e1e8 fixme:ntoskrnl:IoRegisterDriverReinitialization stub: 0x787a54a0 0x541a6f (nil) fixme:ntoskrnl:IoGetDeviceObjectPointer stub: L"\\Device\\LanmanRedirector" 1 0x53e21c 0x53e218 fixme:ntoskrnl:IoGetDeviceObjectPointer stub: L"\\Device\\NetWareRedirector" 1 0x53e21c 0x53e218 wine: Call from 0x7b838b9b to unimplemented function ntoskrnl.exe.IoSetThreadHardErrorMode, aborting wine: Unimplemented function ntoskrnl.exe.IoSetThreadHardErrorMode called at address 0x7b838b9b (thread 0028), starting debugger... wine: Call from 0x7b838b9b to unimplemented function ntoskrnl.exe.IoSetThreadHardErrorMode, aborting --- snip --- MSDN: http://msdn.microsoft.com/en-us/library/ff550342.aspx The driver uses the IoSetThreadHardErrorMode API as follows: --- snip pseudo code --- old_harderror = IoSetThreadHardErrorMode( FALSE); // device: L"\\DosDevices\\C:\\" ... L"\\DosDevices\\D:\\" ... ZwCreateFile( ... device ... ) IoSetThreadHardErrorMode( old_harderror) --- snip pseudo code --- This is to prevent a message box like "There is no disk in the drive. Please insert a disk into drive x" or "Windows cannot access the specified device, path or file." from being shown when the device link is not present or no cdrom is inserted. The driver iterates through all possible drive letters regardless if applicable or not. The return value doesn't really matter for now. 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.

1 4

[Bug 27550] New: SafeDisc 4.x: first opcode byte of kernel32.DebugBreak() API entry must not be "int 3" (0xCC) (Rainbow Six: Vegas 2 fails on startup)
by wine-bugs＠winehq.org 11 Oct '11

11 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=27550 Summary: SafeDisc 4.x: first opcode byte of kernel32.DebugBreak() API entry must not be "int 3" (0xCC) (Rainbow Six: Vegas 2 fails on startup) Product: Wine Version: 1.3.22 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, "Rainbow Six: Vegas 2" complains about a debugger being present. The game shows a message box on startup: "A debugger has been detected" "Unload the debugger and try again" --- snip --- =[ ProtectionID v0.6.4.0 JULY]=- (c) 2003-2010 CDKiLLER & TippeX Build 07/08/10-17:57:05 Ready... Scanning -> Z:\home\focht\.wine\drive_c\Program Files\Ubisoft\Tom Clancy's Rainbow Six Vegas 2\Binaries\R6Vegas2_Game.exe File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 30277768 (01CE0088h) Byte(s) -> File Appears to be Digitally Signed @ Offset 01CDEE00h, size : 01288h / 04744 byte(s) -> File has 1449472 (0161E00h) bytes of appended data starting at offset 01B7D000h [File Heuristics] -> Flag : 00000000000000000100000000000111 (0x00004007) [!] Safedisc v4.85.000 detected ! [i] Appended data contents.... [.] o: 0x01B7D028 / t: <0xA8726B03> <0xEF01996C> <0x00000001> / s: 00302963 byte(s) -> ~deaa13.tmp [.] o: 0x01BC6FC2 / t: <0xA8726B03> <0xEF01996C> <0x0000044C> / s: 00015887 byte(s) -> clcd32.dll [.] o: 0x01BCADF8 / t: <0xA8726B03> <0xEF01996C> <0x0000044C> / s: 00004122 byte(s) -> clcd16.dll [.] o: 0x01BCBE36 / t: <0xA8726B03> <0xEF01996C> <0x0000044D> / s: 00037971 byte(s) -> mcp.dll [.] o: 0x01BD52B2 / t: <0xA8726B03> <0xEF01996C> <0x0000000B> / s: 00005446 byte(s) -> SecDrv04.VxD [.] o: 0x01BD681D / t: <0xA8726B03> <0xEF01996C> <0x00000000> / s: 00072192 byte(s) -> ~e5.0001 [.] o: 0x01BE8244 / t: <0xA8726B03> <0xEF01996C> <0x00000000> / s: 00045056 byte(s) -> PfdRun.pfd [.] o: 0x01BF326C / t: <0xA8726B03> <0xEF01996C> <0x00000000> / s: 00965148 byte(s) -> ~df394b.tmp [CompilerDetect] -> Visual C++ 8.0 (Visual Studio 2005) - Scan Took : 1.569 Second(s) --- snip --- I debugged the protection through various anti-debugging checks and found out a specific check failed. SafeDisc 4.x checks all kernel32 exports and specifically looks for soft-breakpoints (0xcc) on API entries. This fails now for kernel32.DebugBreak() because AJ used an inline asm int 3 (0xcc) to fix bug 24157 The protection treats this as "malicious" soft breakpoint and flags this entry as "bad". bug 24157 -> http://source.winehq.org/git/wine.git/commitdiff/5f06809ab3339e2001de57f18b… - technically a regression. Fortunately SafeDisc only checks the first opcode byte so one could prepend a simple "HOTPATCH" instruction to work around that. Though I'm not sure if this is a "safe" long term solution (in this case it's sufficient). Another way could be forwarding kernel32.DebugBreak to ntdll.DbgBreakPoint I only tested both methods, they work. Though the copy protection later fails for DVD media validation but this is another bug. 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.

1 4

[Bug 13958] New: Services: handle null display names properly when populating SCM db entries
by wine-bugs＠winehq.org 11 Oct '11

11 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=13958 Summary: Services: handle null display names properly when populating SCM db entries Product: Wine Version: 1.0-rc5 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P3 Component: programs AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, there is a bug in services code when one or more services have no display name set (null). If CreateServiceW() is called, it checks for existing services using scmdatabase_find_service_by_displayname(). Unfortunately this internal helper doesn't handle the "null" service name properly while iterating, resulting in exception and messy side effects (although mapped to rpc exception it isn't propagated properly). Following is service db dump with such cases: --- snip --- 000d:trace:service:scmdatabase_load_services Loading service L"BITS" 000d:trace:service:load_service_config Image path = L"svchost.exe -k netsvcs" 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = L"LocalSystem" 000d:trace:service:load_service_config Display name = L"BITS" 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"MountMgr" 000d:trace:service:load_service_config Image path = L"C:\\windows\\system32\\drivers\\mountmgr.sys" 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = L"LocalSystem" 000d:trace:service:load_service_config Display name = L"Mount Manager" 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"MSIServer" 000d:trace:service:load_service_config Image path = L"C:\\windows\\system32\\msiexec.exe /V" 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = L"LocalSystem" 000d:trace:service:load_service_config Display name = L"MSIServer" 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"PnkBstrA" 000d:trace:service:load_service_config Image path = L"C:\\windows\\system32\\PnkBstrA.exe" 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = L"LocalSystem" 000d:trace:service:load_service_config Display name = L"PnkBstrA" 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"PnkBstrB" 000d:trace:service:load_service_config Image path = L"C:\\windows\\system32\\PnkBstrB.exe" 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = L"LocalSystem" 000d:trace:service:load_service_config Display name = L"PnkBstrB" 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"PnkBstrK" 000d:trace:service:load_service_config Image path = L"C:\\windows\\system32\\drivers\\PnkBstrK.sys" 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = L"LocalSystem" 000d:trace:service:load_service_config Display name = L"PnkBstrK" 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"PROCMON13" 000d:trace:service:load_service_config Image path = L"\\??\\C:\\windows\\system32\\Drivers\\PROCMON13.SYS" 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = (null) 000d:trace:service:load_service_config Display name = (null) 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"SecDrv" 000d:trace:service:load_service_config Image path = L"C:\\windows\\system32\\drivers\\\\SECDRV.SYS" 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = L"LocalSystem" 000d:trace:service:load_service_config Display name = L"SecDrv" 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"Spooler" 000d:trace:service:load_service_config Image path = L"C:\\windows\\system32\\spoolsv.exe" 000d:trace:service:load_service_config Group = L"SpoolerGroup" 000d:trace:service:load_service_config Service account name = L"LocalSystem" 000d:trace:service:load_service_config Display name = L"Print Spooler" 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) 000d:trace:service:scmdatabase_load_services Loading service L"VxD" 000d:trace:service:load_service_config Image path = (null) 000d:trace:service:load_service_config Group = (null) 000d:trace:service:load_service_config Service account name = (null) 000d:trace:service:load_service_config Display name = (null) 000d:trace:service:load_service_config Service dependencies : (none) 000d:trace:service:load_service_config Group dependencies : (none) --- snip --- Quick fix: --- snip --- diff --git a/programs/services/services.c b/programs/services/services.c index 806fbb6..d48c985 100644 --- a/programs/services/services.c +++ b/programs/services/services.c @@ -341,7 +341,7 @@ struct service_entry *scmdatabase_find_service_by_displayname(struct scmdatabase LIST_FOR_EACH_ENTRY(service, &db->services, struct service_entry, entry) { - if (strcmpiW(name, service->config.lpDisplayName) == 0) + if (service->config.lpDisplayName && strcmpiW(name, service->config.lpDisplayName) == 0) return service; } --- snip --- Hopefully it's not too late for 1.0 ;-| 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.

1 10

[Bug 18122] New: Add ability to force specific order of notes/howtos
by wine-bugs＠winehq.org 11 Oct '11

11 Oct '11

http://bugs.winehq.org/show_bug.cgi?id=18122 Summary: Add ability to force specific order of notes/howtos Product: WineHQ Apps Database Version: unspecified Platform: Other OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: appdb-unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: focht(a)gmx.net Hello, I would like to see the ability to force the order of NOTES/HOWTOS. I experimented with deleting and re-adding notes or adding some number "prefix" in headline to force ordering but they still appear in some random order. This feature would improve readability as there are several appdb entries which contain a large number of notes/howtos and the most important ones should be displayed first. 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.

1 9

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs July 2011