ADL_Adapter_NumberOfAdapters_Get error

[GoogleCodeExporter]

What is the expected output? What do you see instead?
'PInvokeDelegateFactoryInternalAssembly!PInvokeDelegateFactoryInternalWrapperTyp
e24::ADL_Main_Control_Create' has unbalanced the stack. This is likely because 
the managed PInvoke signature does not match the unmanaged target signature. 
Check that the calling convention and parameters of the PInvoke signature match 
the target unmanaged signature.

What version of the product are you using? latest 
On what operating system? Windows7

Please provide any additional information below.

CPU information works..but ATI throws the error .. since there is no forum ..I 
am posting it as an issue ..
What is wrong?

Please attach a Report created with "File / Save Report...".

Original issue reported on code.google.com by nat2k...@gmail.com on 25 Aug 2010 at 3:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

What happens if you run the (official version of the) Open Hardware Monitor 
outside Visual Studio?

Can you attach an Open Hardware Monitor report (File / Save Report), if it does 
not crash there as well?

Are you using a 32-bit or 64-bit version of Windows?

Can you attach the atiadlxx.dll file from the C:\Windows\System32 folder?

Original comment by moel.mich on 22 Sep 2010 at 11:03

• Changed state: NeedsInfo

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

What is wrong with the calling convention, or how did you solve the problem?

Original comment by moel.mich on 27 Sep 2010 at 10:57

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I am using vs2010 and 64 bit Window7. I have the ATI 5870 card.

I don't have the problem when I run the VS2010 as an Administrator (I am 
already logged in as admin) but I need to also run VS2010 as an admin (right 
click "Run as Administrator"). For now that is how I am working around it.

Original comment by nat2k...@gmail.com on 27 Sep 2010 at 4:23

[GoogleCodeExporter]

If I understand the ADL documentation and the samples right, then the calling 
convention should be StdCall. I just checked once more the managed ADL sample, 
and they used the StdCall convention as well.

Are you using a 32-bit or 64-bit version of Windows?
Can you attach the atiadlxx.dll or atiadlxy.dll file from the 
C:\Windows\System32 folder?

It would be good if I can reproduce the problem here to be sure the problem is 
really solved (and does not just disapear temporarily when using Cdecl).

Original comment by moel.mich on 27 Sep 2010 at 11:25

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I do not use the .NET interface from the ADL samples in the Open Hardware 
Monitor. All the ADL functions are imported directly as native functions in the 
Open Hardware Monitor code, so no .NET support from the ADL is required. I 
haven't been able to reproduce the problem here. If anyone can send me the 
atiadlxx.dll or atiadlxy.dll files causing the problems I might have a chance 
of reproducing it here.

Original comment by moel.mich on 21 Jan 2011 at 1:47

[GoogleCodeExporter]

I am having the same issue.  My application is native C++ Win32.  My 
application talks to my mixed managed and native Win32 dll, which talks to 
Win32 OpenHardwareMonitorLib.dll.  I found out if I change StdCall to Cdecl, 
then this exception doesn't happen.  According to Microsoft documentation about 
CallingConvention.Cdecl, "The caller cleans the stack. This enables calling 
functions with varargs, which makes it appropriate to use for methods that 
accept a variable number of parameters, such as Printf."  I think this fits the 
way OpenHardwareMonitorLib uses ATI APIs.  Thanks for your help.

Original comment by LingYM...@gmail.com on 16 Sep 2011 at 4:52

[GoogleCodeExporter]

I have now been able to reproduce the pInvokeStackImbalance MDA exception, by 
configuring the GUI application to run as x86. This causes the library to run 
in 32-bit mode as well. Changing the CallingConvention to 
CallingConvention.Cdecl does also remove the MDA exception. But I am still not 
really sure if this a correct fix for the problem. The managed sample from AMD 
does not throw any exception in x86 mode for both StdCall and Cdecl.

Original comment by moel.mich on 16 Sep 2011 at 7:44

• Changed state: Accepted

[GoogleCodeExporter]

According to Microsoft Visual Studio documentation, Cdecl is for the caller to 
clean the stack and StdCall is for the callee to clean the stack.  Cdecl would 
be the correct calling convention in ADL.cs.  Cdecl is also being used in 
NVAPI.cs to talk to NVIDIA library.  Therefore, using Cdecl to talk to AMD 
library is appropriate.

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

[GoogleCodeExporter]

Can you change calling convention to Cdecl?  Thank you.

Original comment by LingYM...@gmail.com on 14 May 2012 at 10:32

[GoogleCodeExporter]

This issue was closed by revision r399.

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

• Changed state: Fixed