http://bugs.winehq.org/show_bug.cgi?id=10686
Summary: Marangatu fails with "Object doesn't support this
action"
Product: Wine
Version: 0.9.50.
Platform: PC-x86-64
URL: http://www.set.gov.py/set_htm/softwares/descargas/marang
atui/instalador.exe
OS/Version: Linux
Status: NEW
Keywords: download
Severity: normal
Priority: P2
Component: wine-ole
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: ben(a)atomnet.co.uk
Created an attachment (id=9523)
--> (http://bugs.winehq.org/attachment.cgi?id=9523)
Full terminal log
The eset.exe fails to start, bringing up a message box saying that Runtime
Error 445, Object doesn't support this action and then Wine pagefaults. Full
terminal output and error message attached.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10376
Summary: recent winsock SO_REUSEADDR patch reveals parameter
handling problem in WS_setsockopt
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: wine-net
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
seems recent winsock SO_REUSEADDR patch
--- snip ---
URL:
http://source.winehq.org/git/wine.git/?a=commit;h=58b030c270e68c4e130a7decb…
Author: Kai Blin <kai.blin <at> gmail.com>
Date: Sat Nov 3 08:45:12 2007 +0100
ws2_32: Map SO_REUSEADDR.
BSD socket SO_REUSEADDR is not a complete match, but features like
"allow binding to a port immediately after closing it" seem to be
compatible.
--- snip ---
triggers a code path in WS_setsockopt() which leads to crash.
The cause is an application bug.
EvenBalance PunkBuster "PnkBstrA" service which creates local communication
sockets accidentally passes the value instead of value address to
WS_setsockopt().
The services can be installed and tested with their "pbsvc.exe" tool from
http://www.evenbalance.com/downloads/pbsvc/pbsvc.exe
--- snip ---
..
0015:trace:winsock:WS_setsockopt socket: 005c, level 0xffff, name 0x4, ptr 0x1,
len 1
0015:trace:seh:raise_exception code=c0000005 flags=0 addr=0x76587df5
0015:trace:seh:raise_exception info[0]=00000000
0015:trace:seh:raise_exception info[1]=00000001
0015:trace:seh:raise_exception eax=00000001 ebx=7658e11c ecx=00000002
edx=00000004 esi=0000ffff edi=00000001
0015:trace:seh:raise_exception ebp=617c57a4 esp=617c574c cs=0073 ds=007b
es=007b fs=0033 gs=003b flags=00210293
0015:trace:seh:call_stack_handlers calling handler at 0x7bc38810 code=c0000005
flags=0
--- snip ---
Their source code snippet probably looks like this:
--- snip ---
if (setsockopt( sock, .., ..., (char*)value, value_len) != SOCKET_ERROR)
--- snip ---
Instead of this:
--- snip ---
if (setsockopt( sock, .., ..., (char*)&value, value_len) != SOCKET_ERROR)
--- snip ---
Micro$oft "fixes" such crappy^H^H^H^H^H^Hbuggy applications by using SEH to
catch invalid pointer dereferencing.
If you execute a hand-crafted WS_setsockopt() test case with invalid pointer
value in Windows you will see something like this:
--- snip ---
First-chance exception at 0x719b5280 (mswsock.dll) in test.exe: 0xC0000005:
Access violation reading location 0x00000001.
--- snip ---
Returned last error is WSAEFAULT (bad pointer value/address supplied).
Solution: either wrap the whole function within structured exception handler
(SEH) or use IsBadReadPtr() on passed pointer and return WSAEFAULT if fishy.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=11420
Summary: service control manager API problem: name of named
objects might differ (client vs. service process)
Product: Wine
Version: 0.9.54.
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: advapi32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Created an attachment (id=10552)
--> (http://bugs.winehq.org/attachment.cgi?id=10552)
patch which fixes client vs. service SCM API when using named objects
Hello,
there seems to be a misconception in usage of names for named objects in
service control manager API.
Some people might have experienced such situation: wine hangs for several
seconds on startup (when starting services).
I usually disabled autostart type services (except for builtin ones) and the
problems went away.
Lately while fixing Microsoft Visual Studio .NET installers (2002/2003/2005)
this problem became more and more annoying because the installers and VS.NET
depend on some services, namely "debug manager" (service has to be running).
Consider the following snippet with "service_get_event_handle" trace message
added by me to highlight the problem:
0x9: client (net.exe)
0x11: service process (mdm.exe)
0x12: dispatcher thread
--- snip trace ---
..
0009:trace:advapi:OpenSCManagerW ((null),(null),0x000f003f)
0009:trace:advapi:sc_handle_alloc sc_handle type=0 -> 0x121450
0009:trace:advapi:OpenSCManagerW returning 0x121450 (access : 0x000f003f)
0009:trace:advapi:OpenServiceA 0x121450 "mdm" 983103
0009:trace:advapi:OpenServiceW 0x121450 L"mdm" 983103
0009:trace:advapi:sc_handle_alloc sc_handle type=1 -> 0x121488
0009:trace:advapi:OpenServiceW returning 0x121488
0009:trace:advapi:GetServiceDisplayNameA 0x121450 "mdm" 0x34ee48 0x34fe48
0009:trace:advapi:GetServiceDisplayNameW 0x121450 L"mdm" 0x1214b8 0x34ee08
The Machine Debug Manager service is starting.
0009:trace:advapi:StartServiceA (0x121488,0,(nil))
0009:trace:advapi:StartServiceW 0x121488 0 (nil)
0009:trace:advapi:LockServiceDatabase 0x121450
0009:trace:advapi:LockServiceDatabase returning 0x3c
0009:trace:advapi:service_start_process service_get_event_handle(L"mdm"): 0x40
0011:trace:advapi:LookupPrivilegeValueW L"",L"SeDebugPrivilege",0x34fc80
0011:trace:advapi:LookupPrivilegeValueW L"" -> 00000000-00000014
0011:trace:advapi:AdjustTokenPrivileges
0011:trace:advapi:StartServiceCtrlDispatcherA 0x34fc9c
0011:trace:advapi:service_run_threads Starting 1 pipe listener threads.
Services running as process 16
0012:trace:advapi:service_control_dispatcher 0x121ea8 L"Machine Debug Manager"
0012:trace:advapi:service_control_dispatcher service_get_event_handle(L"Machine
Debug Manager"): 0x48
0009:trace:advapi:UnlockServiceDatabase 0x3c
0009:trace:advapi:StartServiceW returning 0
The Machine Debug Manager service failed to start.
0009:trace:advapi:CloseServiceHandle 0x121488
0009:trace:advapi:sc_handle_destroy_service destroying service 0x121488
0009:trace:advapi:CloseServiceHandle 0x121450
0009:trace:advapi:sc_handle_destroy_manager destroying SC Manager 0x121450
000d:trace:advapi:service_run_threads last user process exited, shutting down
0011:trace:advapi:service_run_threads last user process exited, shutting down
--- snip trace ---
When a service is started, named objects are created to internally communicate
data/events from the service process (dispatcher) to client side SCM API and
vice versa.
Unfortunately there exist service proccesses which pass service names to
dispatcher table (StartServiceCtrlDispatcher) not matching the service name on
the client side (registry "Services" key).
--- snip dlls/advapi32/service.c ---
static DWORD WINAPI service_control_dispatcher(LPVOID arg)
{
service_data *service = arg;
LPWSTR name;
HANDLE pipe, event;
TRACE("%p %s\n", service, debugstr_w(service->name));
/* create a pipe to talk to the rest of the world with */
name = service_get_pipe_name(service->name); <--------- *problem*!
pipe = CreateNamedPipeW(name, PIPE_ACCESS_DUPLEX,
PIPE_TYPE_BYTE|PIPE_WAIT, 1, 256, 256, 10000, NULL );
if (pipe==INVALID_HANDLE_VALUE)
ERR("failed to create pipe for %s, error = %d\n",
debugstr_w(service->name), GetLastError());
HeapFree(GetProcessHeap(), 0, name);
/* let the process who started us know we've tried to create a pipe */
event = service_get_event_handle(service->name); <--------- *problem*!
SetEvent(event);
CloseHandle(event);
..
--- snip dlls/advapi32/service.c ---
As result, different named objects are created and signaled so the client side
can't communicate with the service side using named pipe and events.
This leads to infamous timeout problem (30 sec) and service startup failing.
In case of Microsoft Debug Manager the service is called "mdm" (registry).
The service process itself passes "Microsoft Debug Manager" as name to dispatch
table (see first trace).
Problem: how can both sides communicate a "common" name for named objects?
The service dispatcher part on the service side has only dispatch table data
available which doesn't help much.
I thought about this problem and found a feasible solution ... well call it
"hack" whatever.
If the client side API passes the service name in one of the process startup
parameter members before process creation, the service process' dispatcher
routine is able to access this data and create the named objects used for
communication.
I (ab)used startupinfo "title" member because only wine itself make exclusive
use of most service process startup parameters.
If not considered safe, use reserved/undoc fields...
With that patch applied the services in question start fine and can be
controlled using "net" commands.
No more hangs ;-)
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.
http://bugs.winehq.org/show_bug.cgi?id=12079
Summary: VS.NET7.x/.NET SDK installers fail if re-executed due
to ACTION_StopServices being a stub
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: msi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
.NET Framework SDK, VS.NET 7.x. etc. install "helper" service(s) which get
automagically started.
The installers die if executed again (update/change config) because the running
service blocks file update.
--- snip ---
..
err:msi:ACTION_InstallFiles Failed to copy L"Z:\\mnt\\iso\\Program
Files\\Common Files\\Microsoft Shared\\VS7Debug\\msdbg2.dll" to L"c:\\Program
Files\\Common Files\\Microsoft Shared\\VS7Debug\\msdbg2.dll" (32)
err:msi:ITERATE_Actions Execution halted, action L"InstallFinalize" returned
1603
..
--- snip ---
James, if you find the time, please add "stop services" msi action
implementation (dlls/msi/action.c:ACTION_StopServices).
Although I have a patch, I constantly forget to apply it when tracking down
installer problems.
You could actually help to reduce my patch orgy :)
Thanks.
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.
http://bugs.winehq.org/show_bug.cgi?id=11208
Summary: Unimplemented function in ntsokrnl.exe causes
TrackManiaESWC to fail at startup
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: zgold550(a)gmail.com
Created an attachment (id=10285)
--> (http://bugs.winehq.org/attachment.cgi?id=10285)
output of +relay
Playing TrackManiaESWC is impossible because the game immediately dumps to some
seemingly infinite error of loops. Ran with GIT WINE as of 4:30 on 1/15/08
WINEDEBUG="+relay" ~/progrepo/Wine/wine TmNationsESWCLauncher.exe >
~/TmNationsESWCOutput 2>&1
log is attached.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10407
Summary: TrackMania Nations fails due serveral unimplemented
functions
Product: Wine
Version: CVS/GIT
Platform: PC-x86-64
URL: http://www.trackmanianations.com/
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-misc
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: greg87(a)online.de
wine: Call from 0x7b8442f0 to unimplemented function
ntoskrnl.exe.IoCreateUnprotectedSymbolicLink, aborting
wine: Call from 0x7b8442f0 to unimplemented function
ntoskrnl.exe.ExInitializeZone, aborting
wine: Call from 0x7b8442f0 to unimplemented function
ntoskrnl.exe.ExInterlockedAddLargeInteger, aborting
wine: Call from 0x7b8442f0 to unimplemented function
ntoskrnl.exe.IoCreateSynchronizationEvent, aborting
wine: Call from 0x7b8442f0 to unimplemented function
ntoskrnl.exe.ExInitializeResourceLite, aborting
Next showstopper is for sure the starforce protection...
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=10368
Summary: Corel Draw X3 Won't Install
Product: Wine
Version: 0.9.48.
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-msi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jaimerave(a)gmail.com
Created an attachment (id=9041)
--> (http://bugs.winehq.org/attachment.cgi?id=9041)
Log of the error
The installation is failing when the second stage start.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9929
Summary: Unimplemented function call in Internet Explorer 7
installer
Product: Wine
Version: 0.9.46.
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-crypt32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: nodisgod(a)yahoo.com
Created an attachment (id=8428)
--> (http://bugs.winehq.org/attachment.cgi?id=8428)
Wine output
After using winetricks volnum as per Bug #5351, I started the IE7 installer
binary for Windows XP SP2. After extraction, the installer page faults with
"Call from 0x7b843f50 to unimplemented function wintrust.dll.GenericChainFi
nalProv, aborting" and another message for wintrust.dll.HTTPSCertificateTrust.
I tried to use a native wintrust.dll and also tried changing Windows version to
Windows XP, with same results.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=11936
Summary: window to small in the vc2008 redist installer
Product: Wine
Version: 0.9.57.
Platform: PC
URL: http://download.microsoft.com/download/1/1/1/1116b75a-
9ec3-481a-a3c8-1777b5381140/vcredist_x86.exe
OS/Version: Linux
Status: NEW
Keywords: download, Installer
Severity: normal
Priority: P2
Component: msi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: wine.dev(a)web.de
Created an attachment (id=11238)
--> (http://bugs.winehq.org/attachment.cgi?id=11238)
installer-window in wine
The text of the buttons in the installer of the vc2008 runtime libraries
are not readable.
The location of the Buttons is the same as in w2k,
but in wine, the heigh of the window is to small.
(you need first: sh winetricks volnum)
--
By by ... Detlef
--
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.
http://bugs.winehq.org/show_bug.cgi?id=11673
Summary: WiX cannot validate created .msi, due to lacking
MsiMergeDatabase
Product: Wine
Version: unspecified
Platform: Other
URL: http://bugs.winehq.org/show_bug.cgi?id=11414#c10
OS/Version: other
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: msi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jdahlin(a)async.com.br
Finally, using latest GIT it is possible to generate .msi using WiX, however to
be able to do so one I have to pass in the -sval parameter.
See the instructions in bug 11414, comment 10 for information on how to
reproduce.
Obviously, stubbing out MsiMergeDatabase to always succeed is not enough for
the validation to work properly.
I sent a patch to wine-patches which adds the stub, Adding the stub merely
prevents wine from crashing, but the validation does not succeed.
--
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.