http://bugs.winehq.org/show_bug.cgi?id=16051
--- Comment #6 from Anastasius Focht focht@gmx.net 2008-11-20 18:53:40 --- Hello,
--- quote --- I've believe I've found the cause of one thread going haywire. The thread opens this registry key:
HKLM\SYSTEM\CurrentControlSet\Services\.NET CLR Networking\Performance
And then wants to read value "First Counter" which is missing on Wine. This may be related to missing WBEM support, I'm not sure. Perhaps it should have been created during installation of the dotnet runtime?
If I create a "First Counter" value by hand the thread proceeds to call CreateFileMappingW("Global\netfxcustomperfcounters.1.0"), MapViewOfFile and then reads from this view. If my understanding of this subject is right this is not going to work in Wine.
I was hoping there would be a way to disable performance counters in dotnet but I haven't been able to find one. Removing the registry key did not help. --- quote ---
Well, disabling the use of performance counters/data is not possible. There are several integral parts of .NET which make use of System.Diagnostics.PerformanceCounter component, backed by registry.
That specific ".NET CLR Networking" key problem you mentioned is caused by System.Net.Sockets component which tries to query the established connections perf counter. Harmless because the (first chance) exception gets caught. Async http web requests will succeed despite the failure.
WBEM/WMI is another big hole in wine. The first indication are errors like this:
--- snip --- err:ole:CoGetClassObject class {cf4cc405-e2c5-4ddd-b3ce-5e7582d8c9fa} not registered err:ole:create_server class {cf4cc405-e2c5-4ddd-b3ce-5e7582d8c9fa} not registered fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported err:ole:CoGetClassObject no class object {cf4cc405-e2c5-4ddd-b3ce-5e7582d8c9fa} could be created for context 0x15 --- snip ---
which basically means that the COM class factory for WbemDefaultPathParser failed (0x80004002 -> E_NOINTERFACE). .NET CLR will throw System.TypeInitializationException for System.Management.ManagementPath
The app makes use of System.Management component to query all sorts of informational system data. Fortunately failed native WMI requests don't cause any harm because all managed exceptions are caught by app handlers.
There seems to be a thread stack overflow (recursive SEH chain) in rss feed component which needs more investigation.
Regards