本文介绍了使用.NET 4.0、3.5时，UnmanagedFunctionPointer导致堆栈溢出的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！
问题描述
我在带有try catch块的点击处理程序中有一个简单的函数。如果我在此try catch块中抛出异常，则它会成功捕获该异常。
如果在抛出异常之前对非托管DLL进行了调用，则未处理该异常，并且没被捕获。
什么是无用的DLL调用会破坏我的程序异常处理？
如果我在调试模式下运行该程序，即使未对所有异常都选中异常中断，它仍会捕获异常。该应用程序不会崩溃，并且可以按预期运行。
如果我以调试时启动的方式运行程序，并在崩溃时单击debug，则会收到以下错误消息： Stack cookie检测代码检测到基于堆栈的缓冲区溢出
编辑：
看来堆栈溢出中断了异常处理
我附上了一个导致崩溃的简化程序。
ISOConnection _comm; //This is instantiated at another time in the same thread
//C# test function that crashes when run without a debugger attached
bool DoMagic()
{
try
{
//if I uncomment this line the exception becomes unhandled and cannot be caught
//_comm.ConnectISO15765();
throw new Exception();
}
catch (Exception ex)
{
MessageBox.Show("Caught exception")
}
//Within ISOConnection class
public void ConnectISO15765(){
...
lock(syncLock){
uint returnCode = J2534Interface.PassThruConnect((uint)DeviceId, (uint)ProtocolID.ISO15765, (uint)ConnectFlag.NONE, (uint)BaudRate.ISO15765, ref ChannelId);
//C# UnmanagedFunctionPointer allocation code
[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
public delegate uint PassThruConnect(uint deviceId, uint protocolId, uint flags, uint baudRate, ref uint channelId);
public PassThruConnect Connect;
[DllImport("kernel32.dll")]
public static extern IntPtr LoadLibrary(string dllToLoad);
m_pDll = NativeMethods.LoadLibrary(path);
...
pAddressOfFunctionToCall = NativeMethods.GetProcAddress(m_pDll, "PassThruConnect");
if (pAddressOfFunctionToCall != IntPtr.Zero)
Connect = (PassThruConnect)Marshal.GetDelegateForFunctionPointer(
pAddressOfFunctionToCall,
typeof(PassThruConnect));
//C++ function declaration
long PassThruConnect(unsigned long DeviceID, unsigned long ProtocolID, unsigned long Flags, unsigned long Baudrate, unsigned long *pChannelID);
更新
如果我使用以下命令替换对UnmanagedFunctionPointer PassThurConnect的调用，则不会发生崩溃
[DllImport("op20pt32.dll", EntryPoint = "PassThruConnect", CallingConvention = CallingConvention.Cdecl)]
public static extern uint PassThruConnect2(uint deviceId, uint protocolId, uint flags, uint baudRate, ref uint channelId);
分配UnmanagedFunctionPointer时是否存在某些未执行的操作或执行不正确的操作会导致缺少
这个代码几周前似乎可以正常工作了，这甚至更奇怪了。主要变化是try catch在另一个线程中，而我没有使用lock（syncLock）。现在所有内容都在一个线程中，但是在BackgroundWorker中运行时也发生了相同的崩溃。
UPDATE＃2问题半解决
好，所以我一步一步地回滚了我的提交，直到成功为止。改变的是我从.NET 3.5转到.NET 4.0
.NET 3.5不会崩溃，无论是否连接调试器。如果未附加调试器，则.NET 4.0崩溃。为了排除代码中的错误，我只需删除日志的ConcurrentQueue（我使用的唯一4.0功能），然后将当前代码库转换回3.5，就不会收到此错误。
要确保100％是4.0的问题，然后我将代码库从3.5转换回4.0，并保留了ConcurrentQueue（实际上只是更改了构建选项并进行了重建），并且StackOverflow崩溃了又回来了。
我想使用4.0，有什么想法可以调试此问题吗？
编辑： .NET 4.6.1也崩溃
更新＃3
http://codenition.blogspot.com.au/2010/05/pinvokestackimbalance-in-net-40i-beg .html
在.NET 3.5中，显然pinvokestackimbalance基本上被忽略了，所以问题仍然存在，只是不会使我的应用程序崩溃。
添加以下代码t o当过渡回托管代码时，App.Config导致.NET修复堆栈。性能稍有下降，但可以解决问题。
虽然这确实可以解决问题，但我想知道UnmanagedFunctionPointer出了什么问题，从而导致了问题
<configuration>
<runtime>
<NetFx40_PInvokeStackResilience enabled="1"/>
编辑：此线程不是重复的，另一个已删除...
推荐答案
好，所以问题在于调用约定应该是StdCall而不是Cdecl
这是有道理的，因为通用J2534 API文档指定了以下标头。尽管我提供的头文件没有制定此规范。
extern "C" long WINAPI PassThruConnect
(
unsigned long ProtocolID;
unsigned long Flags
unsigned long *pChannelID
)
其中WINAPI也称为StdCall不像大多数C / C ++库通常使用的Cdecl。
.NET 3.5允许使用错误的调用约定并修复堆栈。从4.0版本开始，情况不再如此，并且将引发PinvokeStackImbalance异常。
您可以强制4.0也通过将以下代码添加到App.Config来修复堆栈。
<configuration>
<runtime>
<NetFx40_PInvokeStackResilience enabled="1"/>
或者您也可以通过将Cdecl更改为StdCall来简单地修改呼叫约定：
[UnmanagedFunctionPointer(CallingConvention.StdCall)]
public delegate uint PassThruConnect(uint deviceId, uint protocolId, uint flags, uint baudRate, ref uint channelID);
这篇关于使用.NET 4.0、3.5时，UnmanagedFunctionPointer导致堆栈溢出的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
参考链接：使用.NET 4.0、3.5时，UnmanagedFunctionPointer导致堆栈溢出 - IT屋-程序员软件开发技术分享社区