I have an application written in VC++ Windows form applications that interacts with various hardware such as A/D cards, GPIB, D/A etc. My customer ran the application on-site, and found that the application is crashing after few seconds. I asked him to monitor memory growth through task manager, and I found that indeed , the memory was growing. So it looks like some problem of memory leakage. Now I want to find where exactly in my code , I am not correctly freeing/allocating memory., but I do not have the access to the onsite PC. I have to do this on my PC which is not having those hardware A/D etc. Is there any software that can accept my exe, and point out the name of functions/code line which is causing the problem, without actually ecxuting my exe?
My exe would not run since I do not have those hardware.
I used Smartbear QATime for this tasks. It is a profiler which can also profile heap allocations. In the report, you can get a list of objects which are still alive and also the line where they have been created.
Related
I have a C++ DLL that is used for authentication that gets loaded by a Windows service for every login.
In that DLL I use the Windows ADSI function ADsOpenObject() to get a user object from Active Directory.
HRESULT hr = ADsOpenObject(L"LDAP://rootDSE",
L"username",
L"password",
m_dwADSFlags,
IID_IDirectorySearch,
(void**)&m_DSSearch);
Generally this works since years. But currently I get the error code
-2147024882 (0x8007000E)
which is OUT_OF_MEMORY. When I restart the service that is using my DLL then it runs fine for weeks but then the errors start occuring.
Now I can't find what is out of memory. The task scheduler looks fine and free memory is plenty.
What can I do to fix that?
which is OUT_OF_MEMORY.
It is E_OUTOFMEMORY, a COM error code. The description isn't very helpful, this error code tends to be returned for any "out of resources" errors by Microsoft code, not just memory. Could by an internal limit being reached, could be a winapi call that fails.
And it is not necessarily limited to the direct software involved. A mishaving device driver that leaks kernel pool memory can be the indirect source of the mishap for example.
You'll be lucky if you can find something back in the Application event log, look both in the machine that reports the error as well as the domain server. Task Manager might give a clue, add the Handles, GDI Objects, USER Object, Commit size, Page pool and NP Pool columns. Pretty hard to give specific advice beyond this. It is no doubt a leak, quacks loudly like one when you have to restart a machine periodically to recover. Good luck hunting it down.
Are you calling Release on m_DSSearch? Also if you are searching you need to call CloseSearchHandle or AbandonSearch. If you are not doing either of those, you could be slowly leaking memory.
Your process could fragment the heap to a point so that ADsOpenObject can't find a consecutive piece of memory that is large enough.
You can use VMMap to profile your memory usage:
http://technet.microsoft.com/en-us/sysinternals/dd535533
You could try enabling low fragmentation heap:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366750(v=vs.85).aspx
If it is now starting to appear and it wasn't earlier, I would suppose one of two possibilities: it has to do with the time (more specifically the year, a milleniumbug of some kind). Another option would be a problem with 32/64 bit architecture.
Now mind that I don't program C++. But I do know a bit about MS errors (I have worked on a MS helpdesk...)
I'm currently working on trying to resolve a crash/exception on an unmanaged C++ application.
The application crashes with some predicatibility. The program basically
process a high volume of files combined with running a bunch of queries through
the access DB.
It's definitely occuring during a file access. The error message is:
"failed reading. Network name is no longer available."
It always seems to be crashing in the same lower level file access code.
It's doing a lower level library Seek(), then a Read(). The exception occurs
during the read.
To further complicate things, we can only get the errors to occur when
we're running an disk balancing utility. The utility essentially examines file
access history and moves more frequently/recently used files to faster storage retrieval
while files that are used less frequently are moved to a slower retrieval area. I don't fully
understand the architecture of the this particular storage device,
but essentially it's got an area for "fast" retrieval and one for "archived/slower."
The issues are more easily/predicably reproducible when the utility app is started and
stopped several times. According to the disk manufacturer, we should be able to run
the utility in the background without effecting the behaviour of the client's main application.
Any suggestions how to proceed here? There are theories floating around here that it's somehow related to latency on the storage device. Is there a way to prove/disprove that? We've written a small sample app that basically goes out accesses/reads a whole mess of files on the drive. We've (so far) been unable to reproduce the issue even running with SmartPools. My thought is to try push the latency theory is to have multiple apps basically reading volumes of files from disk while running the utility application.
The memory usage and CPU usage do not look out of line in the Task Manager.
Thoughts? This is turning into a bit of a hairball.
Thanks,
JohnB
Grab your debug binaries.
Setup Application Verifier and add your application to its list.
Hopefully wait for a crash dumb.
Put that through WinDBG.
Try command: !avrf
See what you get....
I am using an old version of a metastorm workflow designer.
We support this while we rewriting it in Microsoft Technologies.
After a few changes the "MAP" (*.epc) has become exceedingly slow to work with and "PUBLISH".
The publish writes the map and its binaries to the DB which then a service will pick up and execute.
However the publish "hangs" never completing and taking from a completion time of 15 min to in excess of 3 hours but still not completing.
I can see the CPU is being hammered but memory seems fine.
I ran process monitor but it does not show me much which leads me to believe the process is doing something either than the norm or the map has grown to a point which is leading it to destruction.
My question: How else can I profile this black box exe?
Lets say I open some application or process. Did some work with that. Now I closed it.
Need to know whether this application caused any memory leak.
i.e used up some heap memory and not cleared it properly.
Can I get this statistics some how? I'm using Visual Studio (for development) under Windows OS.
Even I would be interested in knowing this information for any 3rd party application.
When an application closes all resources are automatically released by Windows.
A quick & dirty tool to get an indication for memory/resource-leaks inside an application is Perfmon.
The actions executed by an application, can cause other processes to use more memory. SQL Server can make its cache size bigger, maybe you have opened Word or Explorer, the Windows Search engine might kick in because you saved some file. The virus scanner can be more active, etc.....
Have a look at CrtSetDbgFlag:
http://msdn.microsoft.com/en-us/library/5at7yxcs(v=VS.100).aspx
A colleague has been trying to reduce the memory footprint of a 32 bit app running on vista 64 and has noticed some weird behaviour in the reported size of the private working set.
He made some changes and recompiled the app. Then he ran the app and loaded in a data file. The task manager reports that private working set is 98Mb. He then simply renamed the app to 'fred.exe' now when he runs fred.exe and loads the same data file the private working set is reported to be 125Mb. Rename the file back to its original name, repeat and the private working set is back to 98Mb.
Does anyone know what causes this?
This usually happens during full moons.
Did he remember to sacrifice a chicken to Ba'al-ze-Bool, the god of memory?
Vista is doing some smart stuff with application caching (SuperFetch). As I understand it, this is done by application name.
In your case, I'm assuming Vista detected that "originalName.EXE" never benefitted from a large working set, so trimming it to 98 MB helps other apps. The new "fred.exe" on the other hand still gets the default treatment.
The "working set" of an application is (roughly) how much of the application's virtual memory space is currently available to be used. This value fluctuates for many reasons depending on what else is going on in the machine, and does not really reflect the actual memory footprint of the process. It certainly doesn't depend on the name of the executable.
On the other hand, the "private bytes" value is the most useful in measuring the memory footprint of an application. This value reflect the total amount of requests made by the application to allocate more memory, and is not dependent on how much of the application's working set happens to be swapped in at the time.