OpenHardwareMonitorLib Not Loading WinRing0x64.sys for Windows 7 64-bit

[GoogleCodeExporter]

My application is native C++ Win32.  My application talks to my mixed managed 
and native Win32 dll, which talks to Win32 OpenHardwareMonitorLib.dll on 
Windows 7 64-bit.  I've found outOpenHardwareMonitorLib can't load the correct 
WinRing0 driver.  Since my OS is 64-bit, OpenHardwareMonitorLib should load 
WinRing0x64.sys, but it loaded WinRing0.sys because my application is Win32.  
In Win32, IntPtr size is 4, so ExtractDriver method in Ring0.cs decides to load 
WinRing0.sys instead of WinRing064.sys.
There is a System.Environment.Is64BitOperatingSystem in .NET 4 to tell if OS is 
64-bit.  Is it possible to change Ring0.cs to use this instead of checking the 
size of IntPtr to load WinRing0?
Thank you for your help.

Original issue reported on code.google.com by LingYM...@gmail.com on 16 Sep 2011 at 5:05

[GoogleCodeExporter]

This problem never shows up so far because the Open Hardware Monitor is built 
for Any CPU, so it runs as 32-bit process only on 32-bit versions of Windows. 
But of course if used as library only, this can lead to problems, as the 
current implementation is simply wrong.

I will try to avoid adding .NET 4 as requirement. A starting point for fixing 
this issue can be found here:

http://stackoverflow.com/questions/336633/how-to-detect-windows-64-bit-platform-
with-net

Original comment by moel.mich on 16 Sep 2011 at 8:15

• Changed state: Accepted

[GoogleCodeExporter]

Either using Is64BitOperatingSystem in .NET 4 or IsWow64Process from the link 
in the previous comment is a good solution.  Would Ring0.cs be updated soon to 
reflect this change?
Thank you so much.

Original comment by LingYM...@gmail.com on 27 Sep 2011 at 2:03

[GoogleCodeExporter]

Without using a new .NET Framework, you can replace:
{{IntPtr.Size == 4}}
to
{{(ushort)new 
System.Management.ManagementObject("Win32_Processor.DeviceID='CPU0'")["Architect
ure"] == 0}}

Because {{(ushort)new 
System.Management.ManagementObject("Win32_Processor.DeviceID='CPU0'")["Architect
ure"]}} returns 0 for x86 and 9 for x64

Using {{IntPtr.Size}} can erratically retrieve the number of bytes on an 
assembly, when caller is compiled to any processor.

Original comment by lgp1...@gmail.com on 29 Feb 2012 at 7:53

[GoogleCodeExporter]

This issue was closed by revision r399.

Original comment by moel.mich on 11 Jul 2012 at 10:28

• Changed state: Fixed