I am facing some critical issue which might be interesting for whom , those who are playing with window azure sdk. I have created on EXE which read performance counter data like CPU, memory, asp.net session from system like
queryCollection = ExecuteWMIQuery("SELECT * FROM win32_perfformatteddata_perfdisk_physicaldisk");
and I have aded this EXE in startup task of simple asp.net application which i have uploaded on window Azure. Now when i connecting to RDP of that I can see following errors in my event log as per below.
Disabled performance counter data collection from the "ASP.NET_64_2.0.50727" service because the performance counter library for that service has generated one or more errors. The errors that forced this action have been written to the application event log. Correct the errors before enabling the performance counters for this service.
======================================================================
Windows cannot open the 64-bit extensible counter DLL ASP.NET_64_2.0.50727 in a 32-bit environment. Contact the file vendor to obtain a 32-bit version. Alternatively if you are running a 64-bit native environment, you can open the 64-bit extensible counter DLL by using the 64-bit version of Performance Monitor. To use this tool, open the Windows folder, open the System32 folder, and then start Perfmon.exe.
So i am thinking that my EXE trying to fetch performance counter for 32 bit (win32 indicate that) and that will log above error.
So anyone here came across this type of issue , also if my guess is correct then is there any way to implement my EXE logic such way that it can be run smoothly in any environment(32 or 64 bit)?
Hope that this would remain interesting question here!!!
Thanks In Advance Arun.
That is correct. IIS running in Azure is running 64-bit unless you change it to run 32-bit in a startup task. You could try building it with the Any CPU setting. But most likely the best way is to do something like what the sysinternal tools does. They will spawn a new process that runs in 64-bit mode when needed. Then you can handle both.
I encountered this error while migrating to a Azure VM.
Solved it by using the InstallUtil which is located in the Framework64 folder instead of the one in the Framework folder