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=12390
Summary: err:service:service_control_dispatcher failed to create
pipe for L"C-Dilla_CdaC11BA", error = 231
Product: Wine
Version: 0.9.58.
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: amaramrahul(a)gmail.com
"Longman Dictionary of Contemporary English" (ISBN 0 582 50673 5) gets
installed properly from CD-ROM using wine. However when I try to run it using
wine, I get the below error in console:
# wine "C:\Program Files\Longman\LDOCE\ldoce.exe"
err:service:service_control_dispatcher failed to create pipe for
L"C-Dilla_CdaC11BA", error = 231
err:service:service_control_dispatcher failed to create pipe for
L"C-Dilla_CdaC11BA", error = 231
Then a pop-up appears with the message:
"This machine must be re-booted before this product will run correctly. Reboot
now?".
Upon clicking "Yes"/"No", the program exits. I think this has to do something
with copyright. Not sure about this though.
--
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=14594
Summary: crypt32.CryptHashMessage needed for VS.NET 2005
(deployment project type creation)
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: crypt32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
using project wizard to create a "setup/deployment" project type (msi), it
bails due to unimpl crypt32.CryptHashMessage
--- snip ---
..
003f:trace:loaddll:load_native_dll Loaded L"C:\\Program Files\\Microsoft Visual
Studio 8\\Common7\\Tools\\Deployment\\dpplg.dll" at 0x5d010000: native
003f:trace:loaddll:load_native_dll Loaded L"C:\\Program Files\\Microsoft Visual
Studio 8\\Common7\\Tools\\Deployment\\1033\\dpplgui.dll" at 0x5d380000: native
003f:trace:loaddll:load_native_dll Loaded L"C:\\Program Files\\Microsoft Visual
Studio 8\\Common7\\Tools\\Deployment\\dpedt.dll" at 0x5ce70000: native
003f:trace:loaddll:load_native_dll Loaded L"C:\\Program Files\\Microsoft Visual
Studio 8\\VJ#\\bin\\vjsplg.dll" at 0x6ca90000: native
003f:trace:loaddll:load_native_dll Loaded L"C:\\Program Files\\Microsoft Visual
Studio 8\\VJ#\\bin\\1033\\vjsplgui.dll" at 0x6cbc0000: native
003f:trace:seh:raise_exception code=80000100 flags=1 addr=0x7b8432e0
003f:trace:seh:raise_exception info[0]=60b7f840
003f:trace:seh:raise_exception info[1]=60b7fa01
wine: Call from 0x7b8432e0 to unimplemented function
crypt32.dll.CryptHashMessage, aborting
003f:trace:seh:call_stack_handlers calling handler at 0x5cdea7c5 code=80000100
flags=1
003f:trace:seh:call_stack_handlers handler at 0x5cdea7c5 returned 1
003f:trace:seh:call_stack_handlers calling handler at 0x5cdf1732 code=80000100
flags=1
..
--- snip ---
MSDN: http://msdn.microsoft.com/en-us/library/aa380203.aspx
--- stub test ---
031:Call
crypt32.CryptHashMessage(002fd208,00000001,00000001,002fd2e0,002fd2dc,002fd260,002fd248,002fd2f4,002fd2d8)
ret=5cdd6009
0031:fixme:crypt:CryptHashMessage (0x2fd208, 1, 1, 0x2fd2e0, 0x2fd2dc,
0x2fd260, 0x2fd248, 0x2fd2f4): stub
0031:Ret crypt32.CryptHashMessage() retval=00000000 ret=5cdd6009
--- stub test --
Simple stub seems to satisfy it.
For a better stub: MD5 is needed here, the supplied hash algorithm OID
(pHashPara.HashAlgorithm) is "1.2.840.113549.2.5"
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=14571
Summary: ole32.CoGetCallerTID needed for VS.NET 2005
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ole32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
keep the VS.NET 2005 IDE for ~10 secs open and it will crash due to this bug.
--- snip ---
0026:Call user32.InSendMessage() ret=500891c3
0026:Ret user32.InSendMessage() retval=00000000 ret=500891c3
0026:Call KERNEL32.RaiseException(80000100,00000001,00000002,0032f618)
ret=608a4d85
0026:trace:seh:raise_exception code=80000100 flags=1 addr=0x7b8432e0
0026:trace:seh:raise_exception info[0]=608a4e20
0026:trace:seh:raise_exception info[1]=608a4e2a
wine: Call from 0x7b8432e0 to unimplemented function ole32.dll.CoGetCallerTID,
aborting
0026:trace:seh:call_stack_handlers calling handler at 0x506a8ab0 code=80000100
flags=1
--- snip ---
MSDN info here: http://msdn.microsoft.com/en-us/library/ms680683(VS.85).aspx
Implementation is straight forward (minus remote), all the info is there.
I've already verified with a patch.
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=18500
Summary: ntdll.NtQueryInformationProcess: provide simple
ProcessDebugObjectHandle info class handling,
returning "no debugger"
Product: Wine
Version: 1.1.21
Platform: Other
URL: http://www.exeinfo.go.pl/
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ntdll
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
this is a continuation of http://bugs.winehq.org/show_bug.cgi?id=12859#c7
The app queries for unimplemented "ProcessDebugObjectHandle" information class.
--- snip ---
...
0021:Call ntdll.NtSetInformationThread(fffffffe,00000011,00000000,00000000)
ret=004da0d5
0021:fixme:thread:NtSetInformationThread info class 17 not supported yet
0021:Ret ntdll.NtSetInformationThread() retval=c0000002 ret=004da0d5
0021:Call
0021:Call
ntdll.NtQueryInformationProcess(ffffffff,0000001e,c0000002,00000004,00000000)
ret=004da0e4
0021:fixme:ntdll:NtQueryInformationProcess (process=0xffffffff) Unimplemented
information class: ProcessDebugObjectHandle
0021:Ret ntdll.NtQueryInformationProcess() retval=c0000003 ret=004da0e4
...
--- snip ---
Wine already fakes info for such kind of classes, returning "no debugger".
Have a look at dlls/ntdll/process.c:NtQueryInformationProcess, ProcessDebugPort
how it's done and provide simple patch.
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=12859
Summary: HideThreadFromDebugger in NtSetInformationThread
Product: Wine
Version: 0.9.60
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: ntdll
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: readams(a)readams.net
Created an attachment (id=12555)
--> (http://bugs.winehq.org/attachment.cgi?id=12555)
Add HideThreadFromDebugger to winternl.h and to NtSetInformationThread
This API exists in the windows NtSetInformationThread for some reason.
The sensible thing to do in wine here seems to be to just ignore this call.
Patch attached is against 0.9.60.
--
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=21930
Summary: Free Ghost installer crashes during project building
in console
Product: Wine
Version: 1.1.39
Platform: x86
URL: http://www.ethalone.com/download/gi/GIFree.exe
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: ariafan(a)mail.ru
Created an attachment (id=26619)
--> (http://bugs.winehq.org/attachment.cgi?id=26619)
Test installation project
Try in console
wineconsole "c:\program files\Ethalone\Ghost Installer\Bin\GIBuild.exe"
test.gpr
Message is appeared during project building:
fixme:msvcrt:MSVCRT__sopen : pmode 0x81b6 ignored
and later
err:seh:setup_exception_record stack overflow 860 bytes in thread 003f eip
00406df5 esp 00240fd4 stack 0x240000-0x241000-0x340000
testsetup.exe was not created.
See test.gpr in attachment.
--
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=22176
Summary: Rocket Reader 8.3 fails to install
Product: Wine
Version: 1.1.16
Platform: x86
URL: ftp://rocketreader.com/rocketreaderv83.exe
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: lukasz.wojnilowicz(a)gmail.com
CC: julliard(a)winehq.org
Created an attachment (id=27054)
--> (http://bugs.winehq.org/attachment.cgi?id=27054)
WINEDEBUG=+relay on Wine 1.1.41-72-ge9be1b4
At installation, around 75%, the program displays an error (Error changing
registry data), after that it deletes all what it has installed. This error
doesn't appear on Wine 1.1.15 so it's regression. Regression test did give
1c91d54503f9b2afa513dc4dd79bf19bc9bad51a is the first bad commit
commit 1c91d54503f9b2afa513dc4dd79bf19bc9bad51a
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Wed Feb 18 14:44:17 2009 +0100
msvcrt: Don't try to duplicate invalid handles. Don't reset std handles if
we didn't set them.
:040000 040000 2abf5f9a82de1d29b1fccadc658fc3a956388ac4
86464380dfe4aca4c5c11ea2a539a1fc5def03b8 M dlls
Reverting this fault patch enables me to install Rocket Reader.
The program doesn't install on wine 1.1.41. In terminal there is
fixme:richedit:ME_HandleMessage EM_SETMARGINS: stub
fixme:richedit:ME_HandleMessage EM_SETMARGINS: stub
fixme:richedit:ME_HandleMessage EM_SETMARGINS: stub
fixme:richedit:ME_HandleMessage EM_SETMARGINS: stub
fixme:richedit:ME_HandleMessage EM_SETMARGINS: stub
fixme:sfc:SfcIsFileProtected ((nil), L"C:\\Program
Files\\RocketReaderV83\\french.qmc") stub
I'm attaching terminal output with +relay
--
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.