Closed GoogleCodeExporter closed 9 years ago
[deleted comment]
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
[deleted comment]
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
[deleted comment]
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
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
[deleted comment]
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
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
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
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
Can you change calling convention to Cdecl? Thank you.
Original comment by LingYM...@gmail.com
on 14 May 2012 at 10:32
This issue was closed by revision r399.
Original comment by moel.mich
on 11 Jul 2012 at 10:28
Original issue reported on code.google.com by
nat2k...@gmail.com
on 25 Aug 2010 at 3:20