umdh tool compare giving false positive for CreateProcess?

Hi Experts,

I'm doing snapshots with umdh to find memory leaks.  I do my 2 snapshots and then produce a diff (compare) file between them and I get a stacktrace that shows a memory leak as  result of calling CreateProcess.  Thing is I'm releasing both handles that are in the PROCESS_INFORMATION structure I'm passing in with this:

So I'm not sure how else this could be a memory leak.  Is there something else I have to release for CreateProcess?  Could this just be a false positive?

+    1664 (   1664 -      0)      1 allocs      BackTrace15ADAAE0
+       1 (      1 -      0)      BackTrace15ADAAE0      allocations

      ntdll! ?? ::FNODOBFM::`string'+0001913B
      OurProject!OurTask::HandleFile+0000018E (e:\OurProjectSourceDir\OurTask.cpp, 248)
      OurProject!OurTask::Run+00000141 (e:\OurProjectSourceDir\OurTask.cpp, 78)
      OurProject!RunTask+00000070 (e:\OurProjectSourceDir\igeneraltask.cpp, 98)
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

CloseHandle is a windows function and releases windows resources which are not at the c++ heap. so, while it is important to free the resources, those handles don't add or remove anything to memory leaks.

can you post the call of CreateProcess?

if you pass pointer variables as arguments you should verify whether the pointers were properly deleted (or freed).

you were using wide character interface of CreateProcess. this may cause conversion from char to wchar_t what needs additional heap space. however, that memory should be automatically freed after leaving the scope where the CreateProcess was called.

threadyAuthor Commented:
Thanks for taking a look Sara!  :)

DWORD dwCode;

ZeroMemory ( &si, sizeof ( si));
si.cb = sizeof ( si);
si.wShowWindow = bShow ? SW_SHOWNORMAL : SW_HIDE;

CStringW strCommand = L"c:\\Runme.exe";

BOOL bCreatedProcessSuccessfully = CreateProcessW(NULL, strCommand.GetBuffer(), NULL, NULL, TRUE, NORMAL_PRIORITY_CLASS, NULL, NULL, &si, &pi);

Open in new window

threadyAuthor Commented:
Now I'm thinking the GetBuffer call must somehow be the culprit...
Fundamentals of JavaScript

Learn the fundamentals of the popular programming language JavaScript so that you can explore the realm of web development.

CStringW constructor and strCommand.GetBuffer() both will allocate new heap memory.

the memory auztomatically was freed when the destructor of strCommand was called. that happens when the variable goes out-of-scope.

threadyAuthor Commented:
So could this be a false positive then?
the GetBuffer without an argument actually only returns a writeable char buffer (pointer to char) but doesn't allocate additional memory. thje GetBuffer is needed because CreateProcess might need to change the Unicode string. I would increase the buffer size to MAX_PATH, though.

any way, if you put the sequence into {} and let umdh do the measurement after the block, it should stop complaining.

threadyAuthor Commented:
I'm definitely doing the snapshots before the function is entered and after the function is exited.  There's either a false positive here, or I'm missing something...

Can you elaborate more on what you mean by, "CreateProcess might need to change the Unicode string"?

I will put the MAX_PATH as argument to GetBuffer, thanks!

So could this be a false positive then?
it could be a right positive, if CreateProcess needs more space as you provide and uses some extra memory for compensation which then is not freed correctly (in debug mode).

for such cases where I don't know how much buffer is required I personally prefer to using a c buffer like

TCHAR tszCommand[MAX_PATH+1] = { 0 };
 _tcscpy(tszCommand, _T("c:\\Runme.exe"));

Open in new window

If lpApplicationName is NULL, the first white space–delimited token of the command line specifies the module name.
the docs of the CreateProcess give a hint why they may need to modify the command line string. if they want extract tokens from the string they would need to write zero characters for string termination. this is not a fine method and alternatively they might allocate temporary memory instead and also could lead to memory leaks.

assume code like this (deep in windows api):

static wchar_t * tempMemory = 0;
if (wszApplication == NULL)
      // static pointer might be freed on exit 
       tempMemory = (wchar_t*)malloc(MAX_PATH*sizeof(wchar_t);
       return GetLastError();  // here we have a leak 

Open in new window


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
I'm definitely doing the snapshots before the function is entered and after the function is exited.

Open in new window

what do you mean by 'function' ? your function or CreateProcess function?

if the latter you have a leak if strCommand.GetBuffer() adds some extra memory. the internal buffer of the CStringW variable will not released before end-of-scope.

threadyAuthor Commented:
Sara, you're really good.  I placed the application as first parameter and the problem is gone.  Thank you so much!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.