如果预先分配太多内存，P-invoke 调用会失败
我对非托管 DLL 进行了 p-invoke 调用，该调用在我的 WPF 应用程序中失败，但在简单的入门 WPF 应用程序中却失败。我试图找出问题所在，但最终得出的结论是，如果我在调用之前分配太多内存，调用就会失败。我有两个独立的代码块，它们各自都会成功，但如果两者都运行，则会导致失败。 （它们与 p-invoke 调用试图执行的操作无关）。
非托管库中的哪些问题会导致此类问题？我认为托管堆和非托管堆应该自动分离。
据我所知，崩溃发生在从 p 调用的动态加载的辅助 DLL 中。这会不会有什么关系呢？
I've got a p-invoke call to an unmanaged DLL that was failing in my WPF app but not in a simple, starter WPF app. I tried to figure out what the problem was but eventually came to the conclusion that if I assign too much memory before making the call, the call fails. I had two separate blocks of code, both of which would succeed on their own, but that would cause failure if both were run. (They had nothing to do with what the p-invoke call is trying to do).
What kind of issues in the unmanaged library would cause such an issue? I thought that the managed and unmanaged heaps were supposed to be automatically separated.
The crash as far as I can tell is happening in a dynamically loaded secondary DLL from the one p-invoked into. Could that have something to do with it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
非托管代码很容易损坏堆。这种损坏的副作用是非常难以预测的，这取决于损坏的内存之后会发生什么。如果腐败不是发生在关键部位，那么不会发生任何坏事的情况并不少见。改变程序的内存分配模式可以改变结果。
您现在真正知道的是非托管代码不可信。对此采取行动总是很困难，尤其是在托管主机程序中。除非您开始为非托管代码编写单元测试，使用非托管代码来执行它，并找到可以使用非托管调试器处理的可重现的炸弹，否则您将一事无成。
Unmanaged code is prone to corrupt the heap. The side effects of that corruption are very unpredictable, it depends on what happens afterwards with that corrupted memory. It is not uncommon that nothing bad happens if the corruption is not in a crucial location. Changing the memory allocation pattern of your program can change that outcome.
All you really know right now is that the unmanaged code can't be trusted. Doing something about it is invariably hard, especially from a managed host program. You won't get anywhere until you start writing unit tests for that unmanaged code, using unmanaged code to exercise it, and find a reproducible bomb that you could tackle with an unmanaged debugger.
鉴于没有太多信息可供使用，这是在黑暗中拍摄的。
是否有可能非托管 DLL 需要加载到特定的基地址，并且当您分配太多内存或加载其他程序集时，DLL 无法加载到正确的地址。
http://msdn.microsoft.com/en-us/library/w368ysh2。 ASPX
A shot in the dark given there is not much info to work with.
Is it possible that the unmanaged DLL needs to be loaded at a specific base address and when you allocate too much memory or other assemblies are loaded, the DLL is not able to load at the correct address.
http://msdn.microsoft.com/en-us/library/w368ysh2.aspx