http://bugs.winehq.org/show_bug.cgi?id=13964
Hin-Tak Leung htl10@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #14126|0 |1 is obsolete| |
--- Comment #3 from Hin-Tak Leung htl10@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@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@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@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=...
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