本文介绍了使用.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屋-程序员软件开发技术分享社区