• 登录
  • Microsoft.com
  • 中华人民共和国 (中文)
    Brasil (Português)Česká republika (Čeština)Deutschland (Deutsch)España (Español)France (Français)Italia (Italiano)United States (English)Россия (Русский)대한민국 (한국어)日本 (日本語)台灣 (中文)香港特别行政區 (中文)
 
 
Microsoft 开发人员网络
 
 
主页
 
 
技术资源库 
 
 
学习
 
 
下载
 
 
支持
 
 
社区
 
 
 
Microsoft 开发人员网络 > 论坛主页 > Visual C# General > A C#-Unmanaged DLL Memory Challenge
提出问题提出问题
搜索论坛:
  • 搜索 Visual C# General 论坛 搜索 Visual C# General 论坛
  • 搜索所有 MSDN 论坛 搜索所有 MSDN 论坛
 

已答复A C#-Unmanaged DLL Memory Challenge

  • 2008年2月25日 13:20RitchG 用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    投票认定帖子内容有帮助
    0

     

    Greetings.

     

    I am using a graphics toolkit (Altia Design) that creates a group of C source files that are compiled into a DLL. For the current project, the main codebase is in C#. We've completed all the necessary work to get the DLL into C# (DllImport etc.) and that works well. The project runs in the .NET CLR on Windows CE 5.0.

     

    The challenge we now have is that the DLL is running out of memory. When the DLL gets to a certain point and tries to allocate more memory to store a graphic, the allocation fails. Trying to solve the issue on the Altia side has not worked yet (HeapCreate(), HeapAlloc() and so on). Is there a way to tell the CLR to allow this DLL to have more memory?

     

    Thanx.

    ---Ritch

     

    • 回复回复
    • 引用引用
     

答案

  • 2008年2月25日 15:55TaylorMichaelLMVP, 版主用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     已答复
    投票认定帖子内容有帮助
    0

     I wouldn't completely rule out .NET as it is eating up some of the memory.  But I would first determine why the unmanaged code is failing using regular techniques.  Once you've figured that out you can start to determine whether it is because .NET is eating up too much memory, marshaling is going on or whatnot. 

     

    Remember that marshaling almost always involves allocation of memory in both spaces so any place you might be doing marshaling you need to make sure it is being cleaned up.  For example if you were to call Marshal.AllocHGlobal in C# 100 times it will allocate unmanaged memory (and hence affect the unmanaged heap).  However allocating an array of 100 objects in .NET will not impact the unmanaged memory heap (other than what the managed heap takes).  A grep would help identify these potential issues.

     

    Michael Taylor - 2/25/08

    http://p3net.mvps.org

     

    • 回复回复
    • 引用引用
     

全部回复

  • 2008年2月25日 14:49TaylorMichaelLMVP, 版主用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    投票认定帖子内容有帮助
    0

    .NET has no control over unmanaged memory.  .NET allocates its own, separate set of memory.  There is no memory sharing between managed and unmanaged code.  All memory transitions have to be marshalled.  That is what the Marshal class is for.  Therefore if you're running out of memory in the DLL then it is no different than running out of memory in native code.  You have either used up all your available memory or the heap is fragmented too much.  You'll need to figure out why you are running out of memory.  Examining the memory you have remaining and comparing to the amount of memory you need will help identify memory fragmentation.

     

    Michael Taylor - 2/25/08

    http://p3net.mvps.org

     

     

    • 回复回复
    • 引用引用
     
  • 2008年2月25日 15:00RitchG 用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    投票认定帖子内容有帮助
    0

    Excellent.

     

    I could not find any information in the library that indicated .NET was somehow "allocating" memory to unmanaged code; but wanted to check that. I know that Marshalling is necessary when the two memory spaces have to pass/share information but that is not the case here. So we shall continue working on the C side of the house as a normal debugging exercise. And ignore what .NET is doing, correct?

    Thanx.

    ---Ritch

    • 回复回复
    • 引用引用
     
是否需要论坛助手?(常见问题)
 
© 2009 Microsoft Corporation 版权所有。
个人信息中心
|
法律信息
|
MSDN Flash 中心
|
联系我们
|
保留所有权利
|
商标
|
隐私权声明