Guest scewbedew Posted September 16, 2005 Report Posted September 16, 2005 Hi, I'm developing a Home screen plugin for the Smartphone 2003 platform, and I'm experiencing some weird things. Someone out there with some experience in doing this? My questions are mainly in the memory usage/DLL management area. My app is rather graphic intense, and keeps a number of bitmaps in memory. I expected it to grab some serious amount of memory, but I really don't understand what is happening. I search for memory leaks, but I don't understand how to determine if there is a leak or not. The DLL stuff first: ============ My DLL is loaded OK, but when I switch to another home screen (XML) file, my DLL is not unloaded from memory. I have verified that the DLL destructor is called when it is supposed to be called, and that the DLL reference count is 0. After the DLL destructor is called, the dllCanUnloadNow is called repeatedly (endlessly?); each time the return value is S_OK (DLL can be unloaded). Still, my DLL is stuck in memory, and according to the Process Viewer, the reference count is 1? What else can I do? Or is it a "feature" of the home.exe program not to unload DLL's? Memory stuff: ========= OK. I admit. I most probably have some memory leaks in my program. In order to search for potential leaks, I started to monitor the "Heap Memory" performance counter...and got seriously puzzled. When I switch to my DLL, it grabs some memory, as expected. As stated above, this memory i NOT freed when the DLL is supposed to be unloaded. If I switch between two different instances (two XML files) of my DLL, the "Heap Memory" counter continues to rise each time. Not as much as the first time, but some 80-150KB each time. This is nuts, I don't have THAT kind of leaks in my program! I started to doubt that the "Heap Memory" counter showed the complete picture, so I started to investigate other counters as well. ...and became even more puzzled. :arrow: At each switch, the constructor for the new instance of the DLL is called approximately 1.5 seconds before the destructor of the old instance is called. For a brief period of time, the system has to keep 2 instances of the DLL object, resulting in double memory load. That's fine...if the extra memory is freed afterwards, but that doesn't seem to happen. :arrow: For each switch, "Heap Memory" for Home.exe in Process viewer is increased by some 80-160KB. :arrow: Fore each switch, "Available Physical Memory" in Process Viewer decreases by 10-30KB more than the increase in Heap. :arrow: For each switch, the sum of "fixed" blocks in home.exe heap list (according to Heap Walker) is increased by 32 KB, and the sum of "free" blocks is raised so that the total sum of fixed and free blocks matches the Performance Counter. I have an 50-100KB increase in "Free blocks" for each switch!! What is the "truth" hidden amongst these counters? How can I determine if I'm responsible for a memory leak or not? I have no problem accepting that the 32KB increase in fixed blocks most probably is due to a memory leak in my program. But...should I simply ignore the rest of the picture? All counters indicate that memory is consumed, but apart from the 32 KB in fixed blocks, the "memory consumption" is in "free blocks" on the heap (?). Why is all that memory constantly reported as an increase in heap and a decrease in available memory? And...if it is really "free"...why isn't it re-used at next switch? And finally, why isn't my DLL unloaded when it's supposed to be? I'm stuck; I appreciate all help in this matter. :o Regards, /Scewbedew
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now