[Bug 13964] small .NET cmd util: CoWaitForMultipleHandles Unexpected wait termination
wine-bugs at winehq.org
wine-bugs at winehq.org
Fri Jun 20 18:16:10 CDT 2008
http://bugs.winehq.org/show_bug.cgi?id=13964
Hin-Tak Leung <htl10 at users.sourceforge.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #14126|0 |1
is obsolete| |
--- Comment #3 from Hin-Tak Leung <htl10 at users.sourceforge.net> 2008-06-18 00:32:34 ---
It seems to be the NET SDK (which can be installed on its own, or come bundled
with most recent Visual studio, and installed silently, I think).
Editing the [Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug\\] entry
in system.reg and modify it from 'Debugger=vsjitdebugger.exe -p %ld -e %ld'
to back to 'Debugger=winedbg --auto %ld %ld' restores the more agreeable
behavior partly:
It now gives me the thousand lines of CoWaitForMultipleHandles, then the .NET
exception message. Then the winedbg backtrace, instead of another thousand
lines of CoWaitForMultipleHandles (the last bunch causes the .NET exception
message to be lost in the middle of two groups of Cowait..).
So I need to find one more set of registry change to remove the jit debugger
completely for the first set of CoWaitFor..., I think.
--- Comment #4 from Anastasius Focht <focht at gmx.net> 2008-06-18 09:12:31 ---
Hello,
--- quote ---
1) mono linux, win32 mono + wine accepts relative paths or files in current
directory for the argument, .NET doesn't - it needs the full z:\...\...
--- quote ---
Well, mono's implementation of FileIOPermission(FileIOPermissionAccess access,
string path) probably differs then.
Talk about nonconformant behaviour.
--- quote ---
Editing the [Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug\\] entry
in system.reg and modify it from 'Debugger=vsjitdebugger.exe -p %ld -e %ld'
to back to 'Debugger=winedbg --auto %ld %ld' restores the more agreeable
behavior partly:
It now gives me the thousand lines of CoWaitForMultipleHandles, then the .NET
exception message. Then the winedbg backtrace, instead of another thousand
lines of CoWaitForMultipleHandles (the last bunch causes the .NET exception
message to be lost in the middle of two groups of Cowait..).
So I need to find one more set of registry change to remove the jit debugger
completely for the first set of CoWaitFor..., I think.
--- quote ---
The registration of JIT Debugger into AeDebug is part of the .NET SDK/Visual
Studio .NET setup.
The .NET CLR doesn't look at AeDebug first when encountering unhandled
exceptions to decide what to do...
HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework
DbgJITDebugLaunchSetting = 0x10
DbgManagedDebugger = "C:\windows\system32\vsjitdebugger.exe" PID %d APPDOM %d
EXTEXT "%s" EVTHDL %d"
If you want to fall back to default behaviour (avoiding CLR handler), you can
set DbgJITDebugLaunchSetting = 0x0.
This will invoke the crash handler from AeDebug key.
The default managed debugger, which is specified by "DbgManagedDebugger" is
spawned if DbgJITDebugLaunchSetting is set to 0x2 or 0x10.
--
Now for the real problem ...
The managed CLR debugger (vsjitdebugger.exe) calls CoCreateInstance with CLSID
{36BBB745-0999-4FD8-A538-4D4D84E4BD09} -> CLSID_JITDebuggingHost to connect to
local debugging host.
This spawns a local COM server (vsjitdebugger.exe with -embedding param).
Relevant code:
---- snip ----
/* FIXME: should call to rpcss instead */
HRESULT RPC_GetLocalClassObject(REFCLSID rclsid, REFIID iid, LPVOID *ppv)
{
...
get_localserver_pipe_name(pipefn, rclsid);
while (tries++ < MAXTRIES) {
TRACE("waiting for %s\n", debugstr_w(pipefn));
WaitNamedPipeW( pipefn, NMPWAIT_WAIT_FOREVER );
hPipe = CreateFileW(pipefn, GENERIC_READ | GENERIC_WRITE, 0, NULL,
OPEN_EXISTING, 0, 0);
if (hPipe == INVALID_HANDLE_VALUE) {
DWORD index;
DWORD start_ticks;
if (tries == 1) {
if ( (hres = create_local_service(rclsid)) &&
(hres = create_server(rclsid)) )
return hres;
} else {
WARN("Connecting to %s, no response yet, retrying: le is %u\n",
debugstr_w(pipefn), GetLastError());
}
/* wait for one second, even if messages arrive */
start_ticks = GetTickCount();
do {
CoWaitForMultipleHandles(0, 1000, 0, NULL, &index);
} while (GetTickCount() - start_ticks < 1000);
continue;
...
}
---- snip ----
Actually the CoWaitForMultipleHandles(0, 1000, 0, NULL, &index) is wrong.
CoWaitForMultipleHandles() calls MsgWaitForMultipleObjectsEx or
WaitForMultipleObjectsEx depending if rpc/messages need to be pumped.
They expect a least one (valid) handle to wait on.
I bet such CoWaitForMultipleHandles() call fails on Windows too.
Because of the quick failure and the surrounding loop, you get flooded with
that messages.
The "FIXME" before RPC_GetLocalClassObject already indicates: this code needs
some review/rework anyway.
Regards
--- Comment #5 from Hin-Tak Leung <htl10 at users.sourceforge.net> 2008-06-18 20:03:15 ---
Thanks for the analysis!
I also found something else - this MSDN article:
http://msdn.microsoft.com/en-us/library/5hs4b7a6.aspx
mentions two registry entries needed to be deleted to disable JIT debugging.
One of them is the registry entry I mentioned earlier, which removes the 2nd
group of "CoWait..." ; removing the other entry mentioned, removes the first
group of "CoWait...", but it gives a popup message instead saying no jit
debugger instead and ask the user to confirm or cancel debugging. The MSDN
article is
incomplete then - I'll give modifying DbgJITDebugLaunchSetting a try.
Thanks a lot.
--- Comment #6 from Hin-Tak Leung <htl10 at users.sourceforge.net> 2008-06-20 18:16:10 ---
Created an attachment (id=14223)
--> (http://bugs.winehq.org/attachment.cgi?id=14223)
a test binary, plus its source code.
This is the updated source code, and a test binary. The binary is the same as
the binary of the same name inside
http://sourceforge.net/project/showfiles.php?group_id=217165&package_id=279169&release_id=607740
The test binary does something very simple: it reads a .NET assembly and
outputs
its name and version. So you can run it against itself:
GTversionCheck.exe c:\path\GTversionCheck.exe
--
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.
More information about the wine-bugs
mailing list