[Bug 23847] New: ntdll: NtQuerySystemInformation(SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION) should provide NT-style 100ns units (.NET 1.x CLR)

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=23847

           Summary: ntdll:
                    NtQuerySystemInformation(SYSTEM_PROCESSOR_PERFORMANCE_
                    INFORMATION) should provide NT-style 100ns units (.NET
                    1.x CLR)
           Product: Wine
           Version: 1.3.0
          Platform: x86
               URL: http://www.microsoft.com/DownLoads/details.aspx?family
                    id=D7158DEE-A83F-4E21-B05A-009D06457787
        OS/Version: Linux
            Status: NEW
          Keywords: dotnet, download, Installer
          Severity: normal
          Priority: P2
         Component: ntdll
        AssignedTo: wine-bugs at winehq.org
        ReportedBy: focht at gmx.net


Hello,

after bug 17084 (.NET 1.0: imagehlp.ImageGetDigestStream needs more flesh
(assembly registration fails)) was fixed, the installer still fails.

The first blocker is now the presence of some .NET registry keys that ought to
help Mono but break the MS installer itself (path to v1.0.xxx Microsoft CLR
core library is incorrectly constructed, leading to mscorwks.dll load failure). 
You can work around by deleting the following key before running the installer:

--- snip ---
$ wine reg delete "HKLM\Software\Microsoft\.NETFramework"
--- snip ---

Near the end, the installer spawns "regasm.exe" tool several times to register
various assemblies.
Unfortunately the tool crashes with division by zero (+tid,+seh,+relay):

--- snip ---
...
0040:Call ntdll.NtQuerySystemInformation(00000008,031ce960,00000060,00000000)
ret=792cf160
0040:Ret  ntdll.NtQuerySystemInformation() retval=00000000 ret=792cf160
0040:trace:seh:raise_exception code=c0000094 flags=0 addr=0x79243177
ip=79243177 tid=0040
0040:trace:seh:raise_exception  eax=00000000 ebx=ffffffff ecx=00000000
edx=00000000 esi=00000022 edi=00000001
0040:trace:seh:raise_exception  ebp=031ce9f0 esp=031ce940 cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00010246 
--- snip ---

Interestingly there are other calls from the same addresses that don't crash:

--- snip ---
0020:Call ntdll.NtQuerySystemInformation(00000008,0320e960,00000060,00000000)
ret=792cf160
0020:trace:ntdll:NtQuerySystemInformation
(0x00000008,0x320e960,0x00000060,(nil))
000d:Call KERNEL32.SwitchToThread() ret=7929a604
000d:Ret  KERNEL32.SwitchToThread() retval=00000001 ret=7929a604
0020:Ret  ntdll.NtQuerySystemInformation() retval=00000000 ret=792cf160
0020:Call KERNEL32.Sleep(000001f4) ret=792d00bc  
--- snip ---

Using additional "printf" style debugging to dump kernel+user+idle jiffies I
noticed the crashes happen when the values accumulated only small changes in
capture intervals.
It seems the CLR employs some kind of cpu resource utilization calculation
(using certain capture intervals) that breaks if the ticks/time units increment
fall below some threshold.

Windows NT accounts SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION values in 100ns
units.
See: http://msdn.microsoft.com/en-us/library/ms724509.aspx

I fixed dlls/ntdll/nt.c:NtQuerySystemInformation(
SystemProcessorPerformanceInformation class) to convert jiffies to NT-style
100-ns units and it helped to keep the .NET CLR CPU usage calculation happy and
to not let the regasm tool crash anymore (installer succeeded).

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.