Detecting file handle leaks on Windows 7?

[TP]

DrMemory-Windows-1.8.0-8.exe
Windows 7 SP1 64bit
Visual Studio 2008 SP1

I just installed DrMemory, and wanted to see if it could detect file
handle leaks.

So I created handleleak.c:

#include "stdafx.h"
#include <malloc.h>

int _tmain(int argc, _TCHAR* argv[])
{
FILE *fp = fopen("buildlog.htm", "r");
void *junk = malloc(100);
return 0;
}

and compiled with:

/Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE"
/Gm /EHsc /MDd /Fo"Debug\\" /Fd"Debug\vc90.pdb" /W3 /nologo /c /ZI
/TP /errorReport:prompt

Choosing Tools | Dr. Memory, I see the Dr. Memory dialog come up with:

Arguments: -visual_studio -- $(TargetPath)
Command Line: C:\Program Files (x86)\Dr. Memory\bin\drmemory.exe
-visual_studio -- "handleleak\Debug\handleleak.exe"

And when I press OK, I see in the Output window:

Dr. Memory version 1.8.0
Running "Debug\handleleak.exe"

Error #1: LEAK 100 bytes
replace_malloc
d:\drmemory_package\common\alloc_replace.c(2373):
wmain
handleleak\handleleak.cpp(19):

ERRORS FOUND:
0 unique, 0 total unaddressable access(es)
0 unique, 0 total uninitialized access(es)
0 unique, 0 total invalid heap argument(s)
0 unique, 0 total GDI usage error(s)
0 unique, 0 total handle leak(s)
0 unique, 0 total warning(s)
1 unique, 1 total, 100 byte(s) of leak(s)
0 unique, 0 total, 0 byte(s) of possible leak(s)
Details: C:\Users\<username>\AppData\Roaming\Dr.
Memory\DrMemory-handleleak.exe.8800.000\results.txt

So it is correctly finding the memory leak but not the handle leak.

potential_errors.txt just has the following in it which doesn't look
relevant (it always seems to have this):

Potential Error #1: HANDLE LEAK: KERNEL handle 0x00000060 and 0
similar handle(s) were opened but not closed:
system call NtOpenKey
<system call>

Am I doing something wrong?

[Qin Zhao]

Accurately reporting handle leaks is harder than memory leak detection, because there are many cases where the handle is left open on purpose and will be closed at process exit.

Reporting those leaks would be annoying. So we have heuristics to not report them. Your test case match the pattern.

You can try something like have a loop to open 100 handles and another loop to close 50 of them, then you will see the handle leak reported.

The NtOpenKey seems correct, if you are not sure, you can use windbg to run your program and check the handles left open using !handle or !htrace.

--

---
You received this message because you are subscribed to the Google Groups "Dr. Memory Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drmemory-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Derek Bruening]

I filed https://github.com/DynamoRIO/drmemory/issues/1679 for adding a runtime option disabling all the heuristics.

[TP]

I tried:

#include "stdafx.h"
#include <malloc.h>

void leaky2()
{
FILE *fps[100];
int i;

for (i=0; i<100; i++)
fps[i] = fopen("buildlog.htm", "r");
for (i=0; i<50; i++)
fclose(fps[i]);

}

int _tmain(int argc, _TCHAR* argv[])
{

void *junk;

leaky2();
junk = malloc(100);

return 0;
}

And still get:

0 unique, 0 total handle leak(s)

As far as the contents of potential_errors.txt, the actual full printout is:

Potential Error #1: HANDLE LEAK: KERNEL handle 0x00000060 and 0
similar handle(s) were opened but not closed:
system call NtOpenKey
<system call>

GDI32.dll!ReadDisableMetaFilesRegKey
??:0
GDI32.dll!GdiDllInitialize
??:0
USER32.dll!_UserClientDllInitialize
??:0
ntdll.dll!LdrpCallInitRoutine
??:0
ntdll.dll!LdrShutdownProcess
??:0
ntdll.dll!RtlExitUserProcess
??:0
KERNEL32.dll!ExitProcessStub
??:0
MSVCR90D.dll!__crtExitProcess
??:0
MSVCR90D.dll!__freeCrtMemory
??:0
MSVCR90D.dll!exit
??:0
__tmainCRTStartup
??:0
wmainCRTStartup
??:0
KERNEL32.dll!BaseThreadInitThunk
??:0

Which comes from the MSVCRT runtime library startup code so I'm pretty
sure is a false positive (or there's nothing I can do about it).
Personally, I'd say this particular one is not worth reporting at all
in potential_errors.txt.

One possible suggestion for when I choose Tools | Dr. Memory. It
doesn't build the target exe even if there are changes. It would be
nice if it could work like F5 (Start Debugging) does. That is, if
there are changes, ask if you want to build the exe first.

It would also be nice if there was an accelerator (an underlined
letter) for the Dr. Memory menu item. So I could do Alt+T, Y for
example.

On Wed, Feb 11, 2015 at 12:13 PM, 'Qin Zhao' via Dr. Memory Users
<drmemor...@googlegroups.com> wrote:

[Qin Zhao]

On Thu, Feb 12, 2015 at 4:58 PM, TP <win...@gmail.com> wrote:

I tried:

  #include "stdafx.h"
  #include <malloc.h>

  void leaky2()
  {
    FILE *fps[100];
    int i;

    for (i=0; i<100; i++)
      fps[i] = fopen("buildlog.htm", "r");
    for (i=0; i<50; i++)
      fclose(fps[i]);
  }

  int _tmain(int argc, _TCHAR* argv[])
  {
    void *junk;

    leaky2();
    junk = malloc(100);

    return 0;
  }

And still get:

 0 unique,     0 total handle leak(s)

Are you sure you opened any files?

If I just run use your code build and run, there would be no file open, so no file handle leaks.

I modified it a bit and make sure it open files, then I can see a potential handle leak error report:

see the attached result file for details

It is from MSVCRT library does not mean it is not a handle leak.

As I said, it is really hard to tell if it is a real handle leak or false positive. It is even harder to tell if it is a mistake by user program or by the library.

Take your program as an example, the leak callstack is something like:

Potential Error #1: HANDLE LEAK: KERNEL handle 0x0000013c and 49 similar handle(s) were opened but not closed:

# 0 system call NtCreateFile 

# 1 KERNELBASE.dll!CreateFileW   

# 2 KERNEL32.dll!CreateFileWImplementation

# 3 KERNEL32.dll!CreateFileA 

# 4 MSVCR100D.dll!_sopen_helper

# 5 MSVCR100D.dll!_sopen_helper

# 6 MSVCR100D.dll!_sopen_s     

# 7 MSVCR100D.dll!_openfile    

# 8 MSVCR100D.dll!_fsopen      

# 9 MSVCR100D.dll!fopen        

#10 leaky2                                  [c:\users\zhaoqin\documents\visual studio 2010\projects\handle_leak\handle_leak\handle_leak.cpp:10]

#11 wmain                                   [c:\users\zhaoqin\documents\visual studio 2010\projects\handle_leak\handle_leak\handle_leak.cpp:19]

Because Windows typically go through a lot of layers before creating the real handle, it is really hard to tell if it is your code really cause the handle leak or it is a result of the MFC library result. You can try to write code to load and unload a library, you will see what I mean.

The reason we put such error into potential_errors.txt is too many layers, Dr.Memory really does not know if who leaked the handle, program or the library.

 

One possible suggestion for when I choose Tools | Dr. Memory. It
doesn't build the target exe even if there are changes. It would be
nice if it could work like F5 (Start Debugging) does. That is, if
there are changes, ask if you want to build the exe first.

It would also be nice if there was an accelerator (an underlined
letter) for the Dr. Memory menu item. So I could do Alt+T, Y for
example.

 

Those two suggestion sound great, however I am not sure if Visual Studio supports that.

We used the Visual Studio provided external tool functionality to add Dr.Memory into the menu. I am not aware of whether it can automatically detect file changes or short-cut key binding.

It would be great if you know how to do it and contribute to Dr.Memory, so others can benefit from it too.

[TP]

DrMemory-Windows-1.8.0-8.exe and DrMemory-Windows-1.7.0-5.exe
Windows 7 SP1 64bit
Visual Studio 2008 SP1 and Visual Studio 2010 SP1

Okay, I admit that calling fopen with a relative pathname was a bad
idea, so I changed it to an absolute path to my root directory just to
be sure. And I still get:

0 unique, 0 total handle leak(s)

OTOH, I notice that you are probably using VS2010 and I am using
VS2008. So I copied my solution, and opened it with VS2010. I also
noticed you had a .cpp not a .c file. So I also changed to .cpp. Still

get:

0 unique, 0 total handle leak(s)

Then I noticed that you are using Dr. Memory v1.7.0 and I am using v1.8.0

So I uninstalled v1.8.0 and installed v1.7.05 instead. I noticed that
I no longer get a Tools | Dr. Memory menu item and after looking at
the "Release Notes for Version 1.8.0" I see that was just added.
Following the instruction in "Dr. Memory as a Visual Studio Tool" I
get the menu item back. As a side this answers one my earlier
suggestions. The documentation should be changed (and the installer
for 1.8+) so that the title is changed to Dr. Memor&y. Adding the &
will add the accelerator and then Alt+T, Y will start Dr. Memory from
Visual Studio.

So, I'm still stumped as to why you can see leaked handles and I
can't. Can you please post the exact file you are using to show the
handle leaks, and what your project Properties | Configuration
Properties | C/C++ | Command Line and Configuration Properties |
Linker | Command Line are.

You also don't seem to be getting the same:

so that also leads me to think your test file is slightly different
than mine. I also reiterate that THIS particular error should be
ignored. This isn't any handle leak. It is a leak that starts at
wmainCRTStartup then __tmainCRTStartup. Those are not under my control
and thus I can't do anything about them.

On Thu, Feb 12, 2015 at 4:58 PM, 'Qin Zhao' via Dr. Memory Users

[Qin Zhao]

Can you confirm that:
1, you opened file 100 times successfully, check the tps array content.
2, using Windbg to confirm there are 50 file handles left open.
3, check potential_errors.txt if it is listed there.

O used all default settings when create the Windows console executable.

We know there are handles left open by system, that's why we put them in to potential errors, if you confirm it is not an error caused by you, just ignore it.

[Qin Zhao]

Can you confirm that:
1, you opened file 100 times successfully, check the tps array content.
2, using Windbg to confirm there are 50 file handles left open.
3, check potential_errors.txt if it is listed there.

O used all default settings when create the Windows console executable.l

We know there are handles left open by system, that's why we put them in to potential errors, if you confirm it is not an error caused by you, just ignore it.

On Feb 13, 2015 3:29 AM, "TP" <win...@gmail.com> wrote:

[TP]

1. I can confirm (using VS2008 debugger) that the fps array is filled
with non-null values. And obviously, an exception would have been
thrown by the call the fclose() if this were not the case.

2. Run windbg, Open executable handleleak.exe, bp wmain.

step to just before call to leaky2, and do !handle 0 f file, and get:

4 handles of type File

step over leaky2() call, do !handle 0 f file, and get:

54 handles of type File

So there are definitely 50 handles still open.

3. potential_errors.txt is same as it's always been:

1 unique, 1 total potential handle leak(s)

which is the bogus:

that is fired from _tmainCRTStartup, and in my strong opinion should
be ignored, and never show up in potential_errors.txt.

So what's the difference, why can you see file handle leaks and I
can't? What OS are you using?

On Fri, Feb 13, 2015 at 1:04 AM, 'Qin Zhao' via Dr. Memory Users

[TP]

On Thu, Feb 12, 2015 at 4:58 PM, 'Qin Zhao' via Dr. Memory Users
<drmemor...@googlegroups.com> wrote:
>> One possible suggestion for when I choose Tools | Dr. Memory. It
>> doesn't build the target exe even if there are changes. It would be
>> nice if it could work like F5 (Start Debugging) does. That is, if
>> there are changes, ask if you want to build the exe first.
>>
>> It would also be nice if there was an accelerator (an underlined
>> letter) for the Dr. Memory menu item. So I could do Alt+T, Y for
>> example.
>
>
> Those two suggestion sound great, however I am not sure if Visual Studio
> supports that.
> We used the Visual Studio provided external tool functionality to add
> Dr.Memory into the menu. I am not aware of whether it can automatically
> detect file changes or short-cut key binding.
> It would be great if you know how to do it and contribute to Dr.Memory, so
> others can benefit from it too.

I'm not sure about my first suggestion, but implementing the 2nd is
easy. Just change vs_external_tool.c line 64 [1] from:

#define TOOL_TITLE L"Dr. Memory"

to:

#define TOOL_TITLE L"Dr. Memor&y"

(and also change the "Dr. Memory as a Visual Studio Tool" [2] section)

And then you can invoke Dr. Memory from Visual Studio by pressing Alt+T, Y.

[1] https://github.com/DynamoRIO/drmemory/blob/master/tools/vs_external_tool.c#L64

[2] http://drmemory.org/docs/page_running.html

[Qin Zhao]

I tried 1.8.0-8, also works, and I am using Win7 X64.

I can try to run

.\DrMemory-Windows-1.8.0-8\bin\drmemory.exe -debug -verbose 3 -handle_leaks_only -- .\handle_leak.exe

~~Dr.M~~ Dr. Memory version 1.8.0

~~Dr.M~~ Running ".\handle_leak.exe"

~~Dr.M~~ options are "`-verbose` `3` `-handle_leaks_only` -logdir `C:\Users\zhaoqin\Documents\Visual Studio 2010\Projects\handle_leak\Debug\DrMemory-Windows-1.8.0-8\drmemory\logs`

-symcache_dir `C:\Users\zhaoqin\Documents\Visual Studio 2010\Projects\handle_leak\Debug\DrMemory-Windows-1.8.0-8\drmemory\logs\symcache` -lib_blacklist C:\Windows*.d?? -resfile 316

940 "

~~Dr.M~~ log dir is C:\Users\zhaoqin\Documents\Visual Studio 2010\Projects\handle_leak\Debug\DrMemory-Windows-1.8.0-8\drmemory\logs\DrMemory-handle_leak.exe.316940.000

~~Dr.M~~

~~Dr.M~~ NO ERRORS FOUND:

~~Dr.M~~       0 unique,     0 total handle leak(s)

~~Dr.M~~       0 unique,     0 total warning(s)

~~Dr.M~~ ERRORS IGNORED:

~~Dr.M~~       1 potential error(s) (suspected false positives)

~~Dr.M~~          (details: C:\Users\zhaoqin\Documents\Visual Studio 2010\Projects\handle_leak\Debug\DrMemory-Windows-1.8.0-8\drmemory\logs\DrMemory-handle_leak.exe.316940.000\pote

ntial_errors.txt)

~~Dr.M~~ Details: C:\Users\zhaoqin\Documents\Visual Studio 2010\Projects\handle_leak\Debug\DrMemory-Windows-1.8.0-8\drmemory\logs\DrMemory-handle_leak.exe.316940.000\results.txt

It should report the handle leak in potential_errors.txt. If not, can you please check the log file something like  DrMemory-Windows-1.8.0-8\drmemory\logs\DrMemory-handle_leak.exe.316940.000\global.316940.log

search NtCreateFile, you should see lines like:

kernel handle 0x0000007c is opened

...

System calls invoked:

0x000c NtClose                                      50

0x0015 NtAllocateVirtualMemory                       7

0x0016 NtQueryInformationProcess                    31

0x0020 NtQueryVirtualMemory                          3

0x0029 NtTerminateProcess                            2

0x0046 NtQueryVolumeInformationFile                100

0x0052 NtCreateFile                                100

...

Potential Error #1: HANDLE LEAK: KERNEL handle 0x00000164 and 49 similar handle(s) were opened but not closed:

# 0 system call NtCreateFile

# 1 KERNELBASE.dll!CreateFileW    (0x75b5c5f7 <KERNELBASE.dll+0x1c5f7>) modid:5

# 2 KERNEL32.dll!CreateFileWImplementation (0x76023f66 <KERNEL32.dll+0x13f66>) modid:6

# 3 KERNEL32.dll!CreateFileA  (0x760253c4 <KERNEL32.dll+0x153c4>) modid:6

# 4 MSVCR100D.dll!_sopen_helper (0x10129ba5 <MSVCR100D.dll+0x109ba5>) modid:3

# 5 MSVCR100D.dll!_sopen_helper (0x10129647 <MSVCR100D.dll+0x109647>) modid:3

# 6 MSVCR100D.dll!_sopen_s      (0x1012a790 <MSVCR100D.dll+0x10a790>) modid:3

# 7 MSVCR100D.dll!_openfile     (0x100824ed <MSVCR100D.dll+0x624ed>) modid:3

# 8 MSVCR100D.dll!_fsopen       (0x10083835 <MSVCR100D.dll+0x63835>) modid:3

# 9 MSVCR100D.dll!fopen         (0x10083884 <MSVCR100D.dll+0x63884>) modid:3

#10 leaky2          [c:\users\zhaoqin\documents\visual studio 2010\projects\handle_leak\handle_leak\handle_leak.cpp:10] (0x002f1424 <handle_leak.exe+0x11424>) modid:1

#11 wmain           [c:\users\zhaoqin\documents\visual studio 2010\projects\handle_leak\handle_leak\handle_leak.cpp:19] (0x002f1523 <handle_leak.exe+0x11523>) modid:1

Note: @0:00:10.007 in thread 317788

Note: handles created with the same callstack are closed here:

Note: # 0 system call NtClose

Note: # 1 KERNELBASE.dll!CloseHandle    (0x75b4c463 <KERNELBASE.dll+0xc463>) modid:5

Note: # 2 KERNEL32.dll!CloseHandleImplementation (0x76021408 <KERNEL32.dll+0x11408>) modid:6

Note: # 3 MSVCR100D.dll!_close_nolock (0x10128c41 <MSVCR100D.dll+0x108c41>) modid:3

Note: # 4 MSVCR100D.dll!_close        (0x10128b52 <MSVCR100D.dll+0x108b52>) modid:3

Note: # 5 MSVCR100D.dll!_fclose_nolock (0x10082c34 <MSVCR100D.dll+0x62c34>) modid:3

Note: # 6 MSVCR100D.dll!fclose        (0x10082b3d <MSVCR100D.dll+0x62b3d>) modid:3

Note: # 7 leaky2          [c:\users\zhaoqin\documents\visual studio 2010\projects\handle_leak\handle_leak\handle_leak.cpp:12] (0x002f1477 <handle_leak.exe+0x11477>) modid:1

Note: # 8 wmain           [c:\users\zhaoqin\documents\visual studio 2010\projects\handle_leak\handle_leak\handle_leak.cpp:19] (0x002f1523 <handle_leak.exe+0x11523>) modid:1

error end

[TP]

On Sat, Feb 14, 2015 at 8:31 PM, 'Qin Zhao' via Dr. Memory Users
<drmemor...@googlegroups.com> wrote:
> I can try to run
> .\DrMemory-Windows-1.8.0-8\bin\drmemory.exe -debug -verbose 3
> -handle_leaks_only -- .\handle_leak.exe

When I try to run:

drmemory -debug -verbose 3 -handle_leaks_only -- handleleak.exe

I get:

~~Dr.M~~ Dr. Memory version 1.8.0

~~Dr.M~~ Running "handleleak.exe"

~~Dr.M~~ options are "`-verbose` `3` `-handle_leaks_only` -logdir

`C:\Users\<user>\AppData\Roaming\Dr. Memory`
-symcache_dir `C:\Users\<user>\AppData\Roaming\Dr. Memory\symcache`
-lib_blacklist C:\Windows*.d?? -resfile 7112 "
~~Dr.M~~ log dir is C:\Users\<user>\AppData\Roaming\Dr.
Memory\DrMemory-handleleak.exe.7112.000
~~Dr.M~~ ASSERT FAILURE (thread 8032):
d:\drmemory_package\common\utils.c:884: ok_to_fail (error finding
required syscall #)~~Dr.M~~ WARNING: application exited with abnormal
code 0xffffffff

The "General Tips" section of the "Debugging" Wiki page [1] says:

"Try the very latest version of Dr. Memory to see if any problem
you are hitting has already been resolved. Per-version builds are
available as self-extracting archives from [Use the Dr. Memory debug
build by passing this flag to the front-end:"

Where it seems to me something is missing after the phrase "are
available as self-extracting archives from"? Do I need some other
download to use the -debug option? I see a lot of talk about "debug
builds" but don't see where to get them.

[1] https://github.com/DynamoRIO/drmemory/wiki/Debugging#general-tips

[Qin Zhao]

On Sun, Feb 15, 2015 at 5:30 AM, TP <win...@gmail.com> wrote:

On Sat, Feb 14, 2015 at 8:31 PM, 'Qin Zhao' via Dr. Memory Users
<drmemor...@googlegroups.com> wrote:
> I can try to run
> .\DrMemory-Windows-1.8.0-8\bin\drmemory.exe -debug -verbose 3
> -handle_leaks_only -- .\handle_leak.exe

When I try to run:

  drmemory -debug -verbose 3 -handle_leaks_only -- handleleak.exe

I get:

  ~~Dr.M~~ Dr. Memory version 1.8.0
  ~~Dr.M~~ Running "handleleak.exe"
  ~~Dr.M~~ options are "`-verbose` `3` `-handle_leaks_only` -logdir
`C:\Users\<user>\AppData\Roaming\Dr. Memory`
   -symcache_dir `C:\Users\<user>\AppData\Roaming\Dr. Memory\symcache`
-lib_blacklist C:\Windows*.d?? -resfile 7112 "
  ~~Dr.M~~ log dir is C:\Users\<user>\AppData\Roaming\Dr.
Memory\DrMemory-handleleak.exe.7112.000
  ~~Dr.M~~ ASSERT FAILURE (thread 8032):
d:\drmemory_package\common\utils.c:884: ok_to_fail (error finding
required syscall #)~~Dr.M~~ WARNING: application exited with abnormal
code 0xffffffff

That may explain why it fails to report handle leaks.

What's your system. Mine is Win7 SP1 X64 (Version 6.1 Build 7601: Service Pack 1), should be the same as yours.

Can you find out which syscall cannot be found, either from the log or using the debugger?

Are you using some antivirus software, which may interfere with Dr.Memory?

 

The "General Tips" section of the "Debugging" Wiki page [1] says:

   "Try the very latest version of Dr. Memory to see if any problem
you are hitting has already been resolved. Per-version builds are
available as self-extracting archives from [Use the Dr. Memory debug
build by passing this flag to the front-end:"

Thanks, I have updated the wiki page. 

Where it seems to me something is missing after the phrase "are
available as self-extracting archives from"? Do I need some other
download to use the -debug option? I see a lot of talk about "debug
builds" but don't see where to get them.

It is the latest builds, may fix some bugs and you may want to try.

 

[1] https://github.com/DynamoRIO/drmemory/wiki/Debugging#general-tips

[TP]

On Sun, Feb 15, 2015 at 6:03 PM, 'Qin Zhao' via Dr. Memory Users

<drmemor...@googlegroups.com> wrote:
> On Sun, Feb 15, 2015 at 5:30 AM, TP <win...@gmail.com> wrote:
>> On Sat, Feb 14, 2015 at 8:31 PM, 'Qin Zhao' via Dr. Memory Users
>> <drmemor...@googlegroups.com> wrote:
>> When I try to run:
>>
>> drmemory -debug -verbose 3 -handle_leaks_only -- handleleak.exe
>>
>> I get:
>>
>> ~~Dr.M~~ Dr. Memory version 1.8.0
>> ~~Dr.M~~ Running "handleleak.exe"
>> ~~Dr.M~~ options are "`-verbose` `3` `-handle_leaks_only` -logdir
>> `C:\Users\<user>\AppData\Roaming\Dr. Memory`
>> -symcache_dir `C:\Users\<user>\AppData\Roaming\Dr. Memory\symcache`
>> -lib_blacklist C:\Windows*.d?? -resfile 7112 "
>> ~~Dr.M~~ log dir is C:\Users\<user>\AppData\Roaming\Dr.
>> Memory\DrMemory-handleleak.exe.7112.000
>> ~~Dr.M~~ ASSERT FAILURE (thread 8032):
>> d:\drmemory_package\common\utils.c:884: ok_to_fail (error finding
>> required syscall #)~~Dr.M~~ WARNING: application exited with abnormal
>> code 0xffffffff
>
>
> That may explain why it fails to report handle leaks.
> What's your system. Mine is Win7 SP1 X64 (Version 6.1 Build 7601: Service
> Pack 1), should be the same as yours.

I am using the same version of Windows 7 SP1 64bit

TCC LE 13.06.77 x64 Windows 7 [Version 6.1.7601]
Copyright 2013 JP Software Inc. All Rights Reserved

I use TCC/LE [1] as my command shell but I don't think that should matter?

My username has a space character in it. Sometimes that can cause problems?

I have also installed Visual Leak Detector, but since you both install
local copies of dbghelp.dll I thought this didn't matter? Running
"where /t dbghelp.dll" reports:

1087488 11/20/2010 7:24:00 PM C:\Windows\System32\dbghelp.dll
1355280 9/8/2008 2:02:32 PM C:\Program Files\Microsoft
Windows Performance Toolkit\dbghelp.dll
1080656 2/11/2015 1:27:00 AM C:\Program Files (x86)\Visual
Leak Detector\bin\Win32\dbghelp.dll
1369936 2/11/2015 1:27:00 AM C:\Program Files (x86)\Visual
Leak Detector\bin\Win64\dbghelp.dll

> Can you find out which syscall cannot be found, either from the log or using
> the debugger?

I'm not sure how to debug Dr Memory without going through building it
myself? I downloaded DrMemory-1.8.0-8-Source.tar.gz and installed
cmake-2.8.12.2-win32-x86.exe (alongside cmake-3.1.0-win32-x86.exe
which I also had installed), but got a message about "Error in
configuration process, project files may be invalid" for both the
VS2008 and VS2010 generators. It doesn't seem to say what error
though. I noticed:

CMAKE_ASM_COMPILER-NOTFOUND

and in Ungrouped Entries, all(?) of the options for setting directory
locations are blank (which I think just means use the default
location?).

I didn't try actually building Dr Memory yet. I hope I don't have to.

From global.<*>.log I see LOTS of warnings:

WARNING: could not find system call NtAdjustPrivilegesToken
WARNING: could not find system call NtCancelDeviceWakeupRequest
WARNING: could not find system call NtClose
WARNING: could not find system call NtConnectPort
WARNING: could not find system call NtCreateChannel
WARNING: could not find system call NtCreateEvent
WARNING: could not find system call NtCreateEventPair
WARNING: could not find system call NtCreateFile
WARNING: could not find system call NtCreateMutant
WARNING: could not find system call NtCreatePort
WARNING: could not find system call NtCreateSection
WARNING: could not find system call NtCreateSemaphore
WARNING: could not find system call NtCreateSymbolicLinkObject
WARNING: could not find system call NtCreateThread
WARNING: could not find system call NtCreateThreadEx
WARNING: could not find system call NtListenChannel
WARNING: could not find system call NtLoadDriver
WARNING: could not find system call NtMakeTemporaryObject
WARNING: could not find system call NtOpenChannel
WARNING: could not find system call NtOpenFile
WARNING: could not find system call NtOpenSection
WARNING: could not find system call NtQueryOleDirectoryFile
WARNING: could not find system call NtReplyWaitSendChannel
WARNING: could not find system call NtRequestDeviceWakeup
WARNING: could not find system call NtRequestWakeupLatency
WARNING: could not find system call NtSendWaitReplyChannel
WARNING: could not find system call NtSetContextChannel
WARNING: could not find system call NtSetHighWaitLowThread
WARNING: could not find system call NtSetInformationProcess
WARNING: could not find system call NtSetLowWaitHighThread
WARNING: could not find system call NtSetSystemInformation
WARNING: could not find system call NtShutdownSystem
WARNING: could not find system call NtSystemDebugControl
WARNING: could not find system call NtTerminateProcess
WARNING: could not find system call NtTerminateThread
WARNING: could not find system call NtW32Call
WARNING: could not find system call NtWow64CsrNewThread
WARNING: could not find system call NtWow64CsrSetPriorityClass
WARNING: could not find system call NtAcquireCMFViewOwnership
WARNING: could not find system call NtAlpcConnectPort
WARNING: could not find system call NtAlpcCreatePort
WARNING: could not find system call NtAlpcSendWaitReceivePort
WARNING: could not find system call NtClearAllSavepointsTransaction
WARNING: could not find system call NtClearSavepointTransaction
WARNING: could not find system call NtListTransactions
WARNING: could not find system call NtMarshallTransaction
WARNING: could not find system call NtPullTransaction
WARNING: could not find system call NtReleaseCMFViewOwnership
WARNING: could not find system call NtRollbackSavepointTransaction
WARNING: could not find system call NtSavepointComplete
WARNING: could not find system call NtSavepointTransaction
WARNING: could not find system call NtStartTm
WARNING: could not find system call NtWow64CsrBaseClientConnectToServer
WARNING: could not find system call NtWow64CsrBasepGetTempFile
WARNING: could not find system call NtWow64CsrBasepNlsCreateSection
WARNING: could not find system call NtWow64CsrBasepNlsSetMultipleUserInfo
WARNING: could not find system call NtWow64CsrBasepNlsSetUserInfo
WARNING: could not find system call RegisterConsoleIMEInternal
WARNING: could not find system call SetConsoleCommandHistoryMode
WARNING: could not find system call UnregisterConsoleIMEInternal
WARNING: could not find system call QueryConsoleIMEInternal
WARNING: could not find system call NtUserBuildMenuItemList
WARNING: could not find usercall NtUserCallNoParam.CREATESYSTEMTHREADS
WARNING: could not find usercall NtUserCallNoParam.GETMSESSAGEPOS
can't resolve secondary number for NtUserCallNoParam.GETMSESSAGEPOS
syscallWARNING: could not find usercall
NtUserCallNoParam.GETREMOTEPROCID
WARNING: could not find usercall NtUserCallOneParam.GETCURSORPOS
WARNING: could not find usercall NtUserCallOneParam.SETIMESHOWSTATUS
WARNING: could not find usercall NtUserCallOneParam.UNKNOWN
can't resolve secondary number for NtUserCallOneParam.UNKNOWN
syscallWARNING: could not find usercall NtUserCallOneParam.UNKNOWN
WARNING: could not find usercall NtUserCallTwoParam.REGISTERSYSTEMTHREAD
WARNING: could not find system call NtUserCheckImeHotKey
WARNING: could not find system call NtUserCreateDesktop
WARNING: could not find system call NtUserCtxDisplayIOCtl
WARNING: could not find system call NtUserDdeGetQualityOfService
WARNING: could not find system call NtUserDdeSetQualityOfService
WARNING: could not find system call NtUserDisableThreadIme
WARNING: could not find system call NtUserGetClassInfo
WARNING: could not find system call NtUserGetClassLong
WARNING: could not find system call NtUserGetKeyboardLayout
WARNING: could not find system call NtUserGetKeyboardType
WARNING: could not find system call NtUserGetLastInputInfo
WARNING: could not find system call NtUserGetMenuDefaultItem
WARNING: could not find system call NtUserGetMinMaxInfo
WARNING: could not find system call NtUserGetMonitorInfo
WARNING: could not find system call NtUserHardErrorControl
WARNING: could not find system call NtUserInitialize
WARNING: could not find system call NtUserMenuInfo
WARNING: could not find system call NtUserMenuItemInfo
WARNING: could not find system call NtUserMonitorFromPoint
WARNING: could not find system call NtUserMonitorFromRect
WARNING: could not find system call NtUserMonitorFromWindow
WARNING: could not find system call NtUserNotifyProcessCreate
WARNING: could not find system call NtUserQueryInformationThread
WARNING: could not find system call NtUserQueryUserCounters
WARNING: could not find system call NtUserRemoteConnect
WARNING: could not find system call NtUserRemoteRedrawRectangle
WARNING: could not find system call NtUserRemoteRedrawScreen
WARNING: could not find system call NtUserRemoteStopScreenUpdates
WARNING: could not find system call NtUserResolveDesktop
WARNING: could not find system call NtUserSetConsoleReserveKeys
WARNING: could not find system call NtUserSetDbgTag
WARNING: could not find system call NtUserSetInformationProcess
WARNING: could not find system call NtUserSetLogonNotifyWindow
WARNING: could not find system call NtUserSetRipFlags
WARNING: could not find system call NtUserSetScrollBarInfo
WARNING: could not find system call NtUserWin32PoolAllocationStats
WARNING: could not find system call NtUserCallUserpRegisterLogonProcess
WARNING: could not find system call NtUserDwmGetDxRgn
WARNING: could not find system call NtUserDwmHintDxUpdate
WARNING: could not find system call NtUserDesktopHasWatermarkText
WARNING: could not find system call NtGdiUnmapMemFont
WARNING: could not find system call NtGdiDdChangeSurfacePointer
WARNING: could not find system call NtGdiGetColorSpaceforBitmap
WARNING: could not find system call NtGdiSetTextJustification
WARNING: could not find system call NtGdiGetStats
WARNING: could not find system call NtGdiSelectBrush
WARNING: could not find system call NtGdiTileBitBlt
WARNING: could not find system call NtGdiMoveTo
WARNING: could not find system call NtGdiSfmRegisterLogicalSurfaceForSignaling
WARNING: could not find system call NtGdiDwmGetHighColorMode
WARNING: could not find system call NtGdiDwmSetHighColorMode
WARNING: could not find system call NtGdiDwmCaptureScreen
WARNING: could not find system call NtGdiConsoleTextOut
WARNING: could not find system call NtGdiEnumFontChunk
WARNING: could not find system call NtGdiEnumFontClose
WARNING: could not find system call NtGdiEnumFontOpen
WARNING: could not find system call NtGdiSetupPublicCFONT
WARNING: could not find system call NtGdiDwmGetDirtyRgn
WARNING: could not find system call NtGdiDwmGetSurfaceData
WARNING: could not find system call NtGdiGetCodePage

It would be helpful if in drmemory_package\common\utils.c:

bool
get_sysnum(const char *name, drsys_sysnum_t *var, bool ok_to_fail)
{
drsys_syscall_t *syscall;
if (drsys_name_to_syscall(name, &syscall) != DRMF_SUCCESS ||
drsys_syscall_number(syscall, var) != DRMF_SUCCESS) {
ASSERT(ok_to_fail, "error finding required syscall #");
return false;
}
return true;
}

you logged the values of name, var, and value of ok_to_fail.

>
> Are you using some antivirus software, which may interfere with Dr.Memory?

I turned off antivirus (anyway I have it set so it pops up message if
it is going to disable something from running), and it didn't help.

[1] https://jpsoft.com/tccle-cmd-replacement.html

[Derek Bruening]

On Sun, Feb 15, 2015 at 10:53 PM, TP <win...@gmail.com> wrote:

I use TCC/LE [1] as my command shell but I don't think that should matter?

I don't know about TCC/LE in particular, but some consoles can actually cause problems.  E.g., ConEmu invasively injects its own DLL into all child applications, which can affect behavior.  It may be worth trying in another console/shell.

[TP]

On Sun, Feb 15, 2015 at 8:44 PM, 'Derek Bruening' via Dr. Memory Users
<drmemor...@googlegroups.com> wrote:
> I don't know about TCC/LE in particular, but some consoles can actually
> cause problems. E.g., ConEmu invasively injects its own DLL into all child
> applications, which can affect behavior. It may be worth trying in another
> console/shell.

Tried "Visual Studio 2008 Command Prompt"
(ComSpec=C:\Windows\system32\cmd.exe), with:

drmemory -debug -verbose 3 -handle_leaks_only -- handleleak.exe

I turned off all AV.

Still same wrong behavior as before when using TCC/LE as my cmd window
replacement (ComSpec=C:\Program Files\JPSoft\TCCLE13x64\TCC.EXE).

[TP]

Tried on a different Win 7 64bit computer. This one didn't have
VS2008, and I didn't want to have to install that just to get debug
version of C Runtime Library (and just copying msvcr90d.dll didn't
work, got an incorrect "side-by-side configuration" error message). So
had to try with handleleak built with vs2013, but when ran from
standard Command Prompt window:

drmemory -debug -verbose 3 -handle_leaks_only -- handleleak.exe

still got same/similar:

130 "WARNING: could not find system call" messages in global.*.log
ASSERT FAILURE (thread 3784):

d:\drmemory_package\common\utils.c:884: ok_to_fail (error finding
required syscall #)

Ball is back in your court :)

[Derek Bruening]

On Sun, Feb 15, 2015 at 10:53 PM, TP <win...@gmail.com> wrote:

From global.<*>.log I see LOTS of warnings:

  WARNING: could not find system call NtAdjustPrivilegesToken
  WARNING: could not find system call NtCancelDeviceWakeupRequest
  WARNING: could not find system call NtClose
  WARNING: could not find system call NtConnectPort
  WARNING: could not find system call NtCreateChannel
  WARNING: could not find system call NtCreateEvent

 ...

This is not good: it indicates that something is going on with your ntdll.dll -- perhaps some invasive software hooking all of these system calls.  Can you attach a debugger and disassemble these routines and see if they're hooked?  (These are exported functions in ntdll.dll.)  Maybe whatever is happening also explains the CreateProcess strangeness.

[Qin Zhao]

I suspect the same.

Run command line like:

>.\DrMemory-Windows-1.8.0-8\bin\drmemory.exe -debug -handle_leaks_only -dr_debug -dr_ops "-msgbox_mask 0xf" -- ./handle_leak.exe

and use windbg to attach the process when the msgbox popup.

The system call should looks something like:

ntdll!NtClose:

77bff9e0 b80c000000       mov     eax,0xc

77bff9e5 33c9             xor     ecx,ecx

77bff9e7 8d542404         lea     edx,[esp+0x4]

77bff9eb 64ff15c0000000   call    dword ptr fs:[000000c0]

77bff9f2 83c404           add     esp,0x4

77bff9f5 c20400           ret     0x4

If not, it might mean most of your syscalls are hooked and Dr.Memory fail to find all the syscalls it need monitor.

--

[TP]

On Mon, Feb 16, 2015 at 8:06 AM, 'Qin Zhao' via Dr. Memory Users
<drmemor...@googlegroups.com> wrote:
> I suspect the same.
> Run command line like:
>>.\DrMemory-Windows-1.8.0-8\bin\drmemory.exe -debug -handle_leaks_only
>> -dr_debug -dr_ops "-msgbox_mask 0xf" -- ./handle_leak.exe
> and use windbg to attach the process when the msgbox popup.
>
> The system call should looks something like:
>
> ntdll!NtClose:
> 77bff9e0 b80c000000 mov eax,0xc
> 77bff9e5 33c9 xor ecx,ecx
> 77bff9e7 8d542404 lea edx,[esp+0x4]
> 77bff9eb 64ff15c0000000 call dword ptr fs:[000000c0]
> 77bff9f2 83c404 add esp,0x4
> 77bff9f5 c20400 ret 0x4
>
> If not, it might mean most of your syscalls are hooked and Dr.Memory fail to
> find all the syscalls it need monitor.

Tried:

drmemory -debug -handle_leaks_only -dr_debug -dr_ops "-msgbox_mask
0xf" -- handeleak.exe

and got:

ERROR: failed to create process for
"F:\document\Projects\VS2008\ImageProcessing\drmemory\handleleak\Debug\handeleak.exe":
<press enter to dismiss>

In fact any attempt to use the -dr_debug option results in same
message. So don't even have chance to use windbg to attach to the
process.

> On Mon, Feb 16, 2015 at 10:59 AM, 'Derek Bruening' via Dr. Memory Users
> <drmemor...@googlegroups.com> wrote:
>>
>> On Sun, Feb 15, 2015 at 10:53 PM, TP <win...@gmail.com> wrote:
>>>
>>> From global.<*>.log I see LOTS of warnings:
>>>
>>> WARNING: could not find system call NtAdjustPrivilegesToken
>>> WARNING: could not find system call NtCancelDeviceWakeupRequest
>>> WARNING: could not find system call NtClose
>>> WARNING: could not find system call NtConnectPort
>>> WARNING: could not find system call NtCreateChannel
>>> WARNING: could not find system call NtCreateEvent
>>
>> ...
>>
>> This is not good: it indicates that something is going on with your
>> ntdll.dll -- perhaps some invasive software hooking all of these system
>> calls. Can you attach a debugger and disassemble these routines and see if
>> they're hooked? (These are exported functions in ntdll.dll.) Maybe
>> whatever is happening also explains the CreateProcess strangeness.

Aha! While I did turn off my AV as suggested earlier on, I didn't
uninstall it (and don't really want to have to do that). I use the
FREE Comodo Internet Security 8.1 [1]. It has something it calls HIPS
(Host Intrusion Protection) [2] that is:

"A rules-based intrusion prevention system that monitors the
activities of all applications and processes on your computer. HIPS
blocks the activities of malicious programs by halting any action that
could cause damage to your operating system, system-memory, registry
keys or personal data."

The "HIPS Settings" [3] of the Help Manual explains the basics of what
it does (in a mostly non-technical way so you have to infer what they
are REALLY doing). Even though I disabled HIPS, it must still hook in
somewhere in order to do what it does. Disabling HIPS did NOT turn off
the following options:

Enable enhanced protection mode (requires system restart)

Detect shellcode injections

Do heuristic command-line analysis for certain applications

I turned off the last two (and that didn't help), and will report back
on disabling the first one after I restart my system (a longish
process that I try to avoid), but I don't have my hopes up.

I am not all that familiar with other AV products, but my impression
was that at least some others have features like HIPS. So I am a bit
surprised you haven't run into this situation before (and come up with
a way around it :) ?

[1] http://www.comodo.com/home/internet-security/free-internet-security.php

[2] https://help.comodo.com/topic-72-1-623-7587-Introduction-to-Comodo-Internet-Security.html

[3] https://help.comodo.com/topic-72-1-623-7731-HIPS-Settings.html

[TP]

On Mon, Feb 16, 2015 at 3:33 PM, TP <win...@gmail.com> wrote:
> I turned off the last two (and that didn't help), and will report back
> on disabling the first one after I restart my system (a longish
> process that I try to avoid), but I don't have my hopes up.

Turning off Comodo Internet Security 8.1's Enable enhanced protection
mode didn't help. Still see 130 "WARNING: could not find system call"
messages in global.*.log when I run:

drmemory -debug -verbose 3 -handle_leaks_only -- handleleak.exe

Is drmemory likely to run correctly if I install another copy of
Windows 7 inside a virtual machine like VMware Player for Windows
64-bit [1] or VirtualBox [2]? If so, I might try that and not install
any anti-virus software inside the virtual copy of Windows 7.

How likely do you think it will be for you to "fix" Dr Memory so it
can still find system calls even with Comodo Internet Security
installed?

How hard would it be for me to do that? I imagine I'd have to fully
understand DynamicRio.

I'm somewhat motivated to have a free way of detecting memory & handle
leaks for windows applications that will even detect leaks by .exe's
launched by CreateProcess() calls. If I can demonstrate to my
satisfaction that Dr Memory can do this, then I might add supporting
Dr Memory under Comodo as a long term project to work on (if you guys
decline).

[1] https://my.vmware.com/web/vmware/free#desktop_end_user_computing/vmware_player/7_0

[2] https://www.virtualbox.org/

[Qin Zhao]

On Mon, Feb 16, 2015 at 7:58 PM, TP <win...@gmail.com> wrote:

On Mon, Feb 16, 2015 at 3:33 PM, TP <win...@gmail.com> wrote:
> I turned off the last two (and that didn't help), and will report back
> on disabling the first one after I restart my system (a longish
> process that I try to avoid), but I don't have my hopes up.

Turning off Comodo Internet Security 8.1's Enable enhanced protection
mode didn't help. Still see 130 "WARNING: could not find system call"
messages in global.*.log when I run:

  drmemory -debug -verbose 3 -handle_leaks_only -- handleleak.exe

Can you just try to run handleleak.exe or any program directly under windbg, and check the ntdll's NtClose, to see if any unusual asm code there?

 

Is drmemory likely to run correctly if I install another copy of
Windows 7 inside a virtual machine like VMware Player for Windows
64-bit [1] or VirtualBox [2]? If so, I might try that and not install
any anti-virus software inside the virtual copy of Windows 7.

We run Dr.Memory in VM often, no reason not work.

 

How likely do you think it will be for you to "fix" Dr Memory so it
can still find system calls even with Comodo Internet Security
installed?

The system call finding is mostly pattern match, so if we know how Comodo hook those system calls, it is not impossible to do.

I do not have Comodo, and supporting it is not our top priority right now, I am afraid we may not work on it anytime soon.

Plus, I do not have Comodo.

 

How hard would it be for me to do that? I imagine I'd have to fully
understand DynamicRio.

If just to find system call, it may not very hard, as it is just simple pattern match.

The code for finding syscall is at drsyscall/drsyscall_windows.c:

syscall_num_from_name and syscall_num_from_wrapper

and drmgr_decode_sysnum_from_wrapper in "dynamorio/ext/drmgr/drmgr.c"

But Comodo may have many other strange things, which may or may not easy to handle.

 

I'm somewhat motivated to have a free way of detecting memory & handle
leaks for windows applications that will even detect leaks by .exe's
launched by CreateProcess() calls. If I can demonstrate to my
satisfaction that Dr Memory can do this, then I might add supporting
Dr Memory under Comodo as a long term project to work on (if you guys
decline).

We appreciate your interest of contribution.

 

[1] https://my.vmware.com/web/vmware/free#desktop_end_user_computing/vmware_player/7_0

[2] https://www.virtualbox.org/

[TP]

On Mon, Feb 16, 2015 at 5:47 PM, 'Qin Zhao' via Dr. Memory Users
<drmemor...@googlegroups.com> wrote:
> On Mon, Feb 16, 2015 at 7:58 PM, TP <win...@gmail.com> wrote:
>>
>> On Mon, Feb 16, 2015 at 3:33 PM, TP <win...@gmail.com> wrote:
>> > I turned off the last two (and that didn't help), and will report back
>> > on disabling the first one after I restart my system (a longish
>> > process that I try to avoid), but I don't have my hopes up.
>>
>> Turning off Comodo Internet Security 8.1's Enable enhanced protection
>> mode didn't help. Still see 130 "WARNING: could not find system call"
>> messages in global.*.log when I run:
>>
>> drmemory -debug -verbose 3 -handle_leaks_only -- handleleak.exe
>
>
> Can you just try to run handleleak.exe or any program directly under windbg,
> and check the ntdll's NtClose, to see if any unusual asm code there?

windbg 6.12
Windows 7 SP1 64bit

Assuming I'm doing this correctly, in Windbg I opened handleleak.exe, then did:

0:000> x ntdll!*close
00000000`7792d790 ntdll!TppETWPoolClose = <no type information>
00000000`778d13a0 ntdll!ZwClose = <no type information>
00000000`778d13a0 ntdll!NtClose = <no type information>
00000000`7794c300 ntdll!ResFindClose = <no type information>

In the Disassembly Window I put ntdll!NtClose in the Offset field and see:

ntdll!ZwSetInformationThread:
00000000`778d1380 4c8bd1 mov r10,rcx
00000000`778d1383 b80a000000 mov eax,0Ah
00000000`778d1388 0f05 syscall
00000000`778d138a c3 ret
00000000`778d138b 0f1f440000 nop dword ptr [rax+rax]
ntdll!ZwSetEvent:
00000000`778d1390 4c8bd1 mov r10,rcx
00000000`778d1393 b80b000000 mov eax,0Bh
00000000`778d1398 0f05 syscall
00000000`778d139a c3 ret
00000000`778d139b 0f1f440000 nop dword ptr [rax+rax]
ntdll!ZwClose:
00000000`778d13a0 4c8bd1 mov r10,rcx
00000000`778d13a3 b80c000000 mov eax,0Ch
00000000`778d13a8 0f05 syscall
00000000`778d13aa c3 ret
00000000`778d13ab 0f1f440000 nop dword ptr [rax+rax]
ntdll!NtQueryObject:
00000000`778d13b0 4c8bd1 mov r10,rcx
00000000`778d13b3 b80d000000 mov eax,0Dh
00000000`778d13b8 0f05 syscall
00000000`778d13ba c3 ret
00000000`778d13bb 0f1f440000 nop dword ptr [rax+rax]
ntdll!ZwQueryInformationFile:
00000000`778d13c0 4c8bd1 mov r10,rcx
00000000`778d13c3 b80e000000 mov eax,0Eh
00000000`778d13c8 0f05 syscall
00000000`778d13ca c3 ret
00000000`778d13cb 0f1f440000 nop dword ptr [rax+rax]
ntdll!NtOpenKey:
00000000`778d13d0 4c8bd1 mov r10,rcx
00000000`778d13d3 b80f000000 mov eax,0Fh
00000000`778d13d8 0f05 syscall
00000000`778d13da c3 ret
00000000`778d13db 0f1f440000 nop dword ptr [rax+rax]

which doesn't look like what you mentioned earlier?

>> Is drmemory likely to run correctly if I install another copy of
>> Windows 7 inside a virtual machine like VMware Player for Windows
>> 64-bit [1] or VirtualBox [2]? If so, I might try that and not install
>> any anti-virus software inside the virtual copy of Windows 7.
>
>
> We run Dr.Memory in VM often, no reason not work.

Okay. I'm in the process of using VirtualBox to install Windows 10
Technical Preview [1], Visual Studio Community 2013 [2], and the
Standalone Debugging Tools for Windows (WinDbg) from the SDK for
Windows 8.1 [3]. I'll let you know what I find out.

>> How likely do you think it will be for you to "fix" Dr Memory so it
>> can still find system calls even with Comodo Internet Security
>> installed?
>
>
> The system call finding is mostly pattern match, so if we know how Comodo
> hook those system calls, it is not impossible to do.
> I do not have Comodo, and supporting it is not our top priority right now, I
> am afraid we may not work on it anytime soon.
> Plus, I do not have Comodo.

Well... Comodo Internet Security [4] is free :) There is a CIS Pro
version that you have to buy, but I have just been using the free
version for years. It is extremely powerful and certainly seems able
to notify me when programs try to do all sorts of low-level stuff.

[1] http://windows.microsoft.com/en-us/windows/preview-iso

[2] http://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx

[3] https://msdn.microsoft.com/en-US/windows/hardware/gg454513

[4] https://www.comodo.com/home/internet-security/free-internet-security.php

[Derek Bruening]

On Tue, Feb 17, 2015 at 2:02 AM, TP <win...@gmail.com> wrote:

On Mon, Feb 16, 2015 at 5:47 PM, 'Qin Zhao' via Dr. Memory Users
<drmemor...@googlegroups.com> wrote:
> Can you just try to run handleleak.exe or any program directly under windbg,
> and check the ntdll's NtClose, to see if any unusual asm code there?

windbg 6.12
Windows 7 SP1 64bit

In the Disassembly Window I put ntdll!NtClose in the Offset field and see:

  ntdll!ZwClose:
  00000000`778d13a0 4c8bd1          mov     r10,rcx
  00000000`778d13a3 b80c000000      mov     eax,0Ch
  00000000`778d13a8 0f05            syscall
  00000000`778d13aa c3              ret
  00000000`778d13ab 0f1f440000      nop     dword ptr [rax+rax]

That's 64-bit.  Weren't you running a 32-bit app before?

[Derek Bruening]

On Mon, Feb 16, 2015 at 6:33 PM, TP <win...@gmail.com> wrote:

Tried:

  drmemory -debug -handle_leaks_only -dr_debug -dr_ops "-msgbox_mask
0xf" -- handeleak.exe

and got:

  ERROR: failed to create process for
"F:\document\Projects\VS2008\ImageProcessing\drmemory\handleleak\Debug\handeleak.exe":
  <press enter to dismiss>

It looks like a typo: "handeleak.exe" instead of "handleleak.exe".

[TP]

On Mon, Feb 16, 2015 at 11:02 PM, TP <win...@gmail.com> wrote:
> Okay. I'm in the process of using VirtualBox to install Windows 10
> Technical Preview [1], Visual Studio Community 2013 [2], and the
> Standalone Debugging Tools for Windows (WinDbg) from the SDK for
> Windows 8.1 [3]. I'll let you know what I find out.

Windows 10 Technical Preview
DrMemory-Windows-1.8.16482-0x0371d69-sfx.exe

[C:\<user>\George\Documents\Visual Studio 2013\Projects\handleleak\Debug]ver
TCC LE 13.06.77 x64 Windows 8 [Version 6.2.9200]
[C:\Users\<user>\Documents\Visual Studio 2013\Projects\handleleak\Debug]drmemory
ERROR: this version of Windows is not supported by Dr. Memory.

Sigh.

[TP]

On Mon, Feb 16, 2015 at 11:18 PM, 'Derek Bruening' via Dr. Memory

Users <drmemor...@googlegroups.com> wrote:
> On Tue, Feb 17, 2015 at 2:02 AM, TP <win...@gmail.com> wrote:
>>
>> On Mon, Feb 16, 2015 at 5:47 PM, 'Qin Zhao' via Dr. Memory Users
>> <drmemor...@googlegroups.com> wrote:
>> > Can you just try to run handleleak.exe or any program directly under
>> > windbg,
>> > and check the ntdll's NtClose, to see if any unusual asm code there?
>>
>> windbg 6.12
>> Windows 7 SP1 64bit
>>
>> In the Disassembly Window I put ntdll!NtClose in the Offset field and see:
>>
>> ntdll!ZwClose:
>> 00000000`778d13a0 4c8bd1 mov r10,rcx
>> 00000000`778d13a3 b80c000000 mov eax,0Ch
>> 00000000`778d13a8 0f05 syscall
>> 00000000`778d13aa c3 ret
>> 00000000`778d13ab 0f1f440000 nop dword ptr [rax+rax]
>
>
> That's 64-bit. Weren't you running a 32-bit app before?

That' still the handleleak.exe I built with Debug | Win32
configuration. I am running it under Windows 7 SP1 64bit however.

Windbg is from "C:\Program Files\Debugging Tools for Windows (x64)\windbg.exe"
WinDbg 6.12.0002.633 AMD64

The dynamorio Debugging wiki page says in the Debugging On Windows |
Debugging Tools section [1]

"Install the Debugging Tools for Windows to get the full WinDbg. For
debugging 32-bit applications, we recommend using WinDbg version
6.3.0017, not the newer versions 6.4 through 6.11, as they have
problems displaying callstacks involving DynamoRIO code. However, if
you cannot obtain 6.3.0017 (it is no longer supported), get the latest
version. You'll have to go to extra effort to get a callstack when
attaching at a DynamoRIO messagebox midway through execution for a
32-bit process (see below). For 64-bit, use the most recent version of
WinDbg."

But I don't think I can download WinDbg 6.3 anymore? Would running the
newer Windbg 6.12 show the same wrong disassembly info? Or maybe I'm
not using Windbg correctly. I haven't had to use it very often in the
past. Mainly for looking at minidumps.

[1] https://github.com/DynamoRIO/dynamorio/wiki/Debugging#debugging-tools

[TP]

Oooops. Okay. When I now try:

drmemory -debug -handle_leaks_only -dr_debug -dr_ops "-msgbox_mask

0xf" -- handleleak.exe

I get a DynamoRIO Notice message box that says

Internal Error: DynamoRIO debug check failure:
d:\drmemory_package\dynamorio\core\win32\ntdll.c:569 (byte *)
get_proc_address(ntdllh, syscall_names[i]) != NULL && blah blah blah

And when I fire up WinDbg 6.12.0002.633 AMD64 (which may be too new a
version of Windbg?), and then File | Attach to a Process, and pick my
handleleak.exe process, making sure to turn on the Noninvasive
checkbox, I see:

ntdll!NtRaiseHardError:
00000000`778d25e0 4c8bd1 mov r10,rcx
00000000`778d25e3 b830010000 mov eax,130h
00000000`778d25e8 0f05 syscall
--> 00000000`778d25ea c3 ret

where I am at the ret statement.

[Derek Bruening]

On Tue, Feb 17, 2015 at 4:11 AM, TP <win...@gmail.com> wrote:

On Mon, Feb 16, 2015 at 11:18 PM, 'Derek Bruening' via Dr. Memory
Users <drmemor...@googlegroups.com> wrote:
> On Tue, Feb 17, 2015 at 2:02 AM, TP <win...@gmail.com> wrote:
>>
>> On Mon, Feb 16, 2015 at 5:47 PM, 'Qin Zhao' via Dr. Memory Users
>> <drmemor...@googlegroups.com> wrote:
>> > Can you just try to run handleleak.exe or any program directly under
>> > windbg,
>> > and check the ntdll's NtClose, to see if any unusual asm code there?
>>
>> windbg 6.12
>> Windows 7 SP1 64bit
>>
>> In the Disassembly Window I put ntdll!NtClose in the Offset field and see:
>>
>>   ntdll!ZwClose:
>>   00000000`778d13a0 4c8bd1          mov     r10,rcx
>>   00000000`778d13a3 b80c000000      mov     eax,0Ch
>>   00000000`778d13a8 0f05            syscall
>>   00000000`778d13aa c3              ret
>>   00000000`778d13ab 0f1f440000      nop     dword ptr [rax+rax]
>
>
> That's 64-bit.  Weren't you running a 32-bit app before?

That' still the handleleak.exe I built with Debug | Win32
configuration. I am running it under Windows 7 SP1 64bit however.

Windbg is from "C:\Program Files\Debugging Tools for Windows (x64)\windbg.exe"
WinDbg 6.12.0002.633 AMD64

If you use the 64-bit windbg, it will see both the 32-bit and 64-bit ntdll.  You want to disassemble the 32-bit ntdll, *not* the 64-bit ntdll, so look at the module list ("lm") and find the name it gave the 32-bit (probably has its base address, "ntdll_776c0000" or sthg) and then run "U ntdll_776c0000!NtClose".  Or, just use the 32-bit windbg.

[Derek Bruening]

On Mon, Feb 16, 2015 at 7:58 PM, TP <win...@gmail.com> wrote:

How likely do you think it will be for you to "fix" Dr Memory so it
can still find system calls even with Comodo Internet Security
installed?

How hard would it be for me to do that? I imagine I'd have to fully
understand DynamicRio.

Please file an issue in our issue tracker.  This can be a complex topic with multiple possible solutions of varying difficulty and effectiveness.

[TP]

On Tue, Feb 17, 2015 at 7:34 AM, 'Derek Bruening' via Dr. Memory Users

Aha! From "How to install WinDbg 32-bit on 64-bit system" [1], I see
that after I use "Windows SDK for Windows 7.1 and .NET Framework 4"
[2] to get the Debugging Tools for Windows, I STILL need to run:

C:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools
for Windows\dbg_x86.msi

in order to get the 32bit version of Windbg.

Once that is done, when you use the Start Menu to search for Windbg
you'll get TWO entries. I renamed the x86 version to "WinDbg (x86)"
just so I could tell the difference. This info should probably be
added to your wiki somewhere. It wasn't clear to me before that there
are multiple architecture/platform versions of WinDbg and that you
have to use the right one. This is unlike the Visual Studio debugger
which just "does the right thing".

Here is what I get now for WinDbg 6.12.0002.633 X86, when I do U ntdll!NtClose:

0:000> U ntdll!NtClose
ntdll!NtClose:
77a7f9e0 ff251e00ae71 jmp dword ptr ds:[71AE001Eh]
77a7f9e6 c9 leave
77a7f9e7 8d542404 lea edx,[esp+4]
77a7f9eb 64ff15c0000000 call dword ptr fs:[0C0h]
77a7f9f2 83c404 add esp,4
77a7f9f5 c20400 ret 4

Sorry for all my confusion.

[1] https://social.msdn.microsoft.com/forums/windowsdesktop/en-us/cd004535-75f1-48ee-9176-574b344ddce1/how-to-install-windbg-32bit-on-64bit-system

[2] https://www.microsoft.com/en-us/download/confirmation.aspx?id=8279

[Derek Bruening]

On Tue, Feb 17, 2015 at 12:05 PM, TP <win...@gmail.com> wrote:

Here is what I get now for WinDbg 6.12.0002.633 X86, when I do U ntdll!NtClose:

   0:000> U ntdll!NtClose
   ntdll!NtClose:
   77a7f9e0 ff251e00ae71    jmp     dword ptr ds:[71AE001Eh]
   77a7f9e6 c9              leave
   77a7f9e7 8d542404        lea     edx,[esp+4]
   77a7f9eb 64ff15c0000000  call    dword ptr fs:[0C0h]
   77a7f9f2 83c404          add     esp,4
   77a7f9f5 c20400          ret     4

Follow the hook: what library contains 71AE001E?  If it's not in a library, disassemble the address stored there until you find calls into a library.  Who is the owner of that library?  That's your culprit.

[TP]

Okay, not sure if I follow you but...

If I open the Memory window, and enter 71AE001Eh with display format =
Pointer and Sy? I see:

71ae001e 71af000a

If I then disassemble 71af000a I see:

No prior disassembly possible
71af000a 57 push edi
71af000b 52 push edx
71af000c 51 push ecx
71af000d 50 push eax
71af000e bf3b00af71 mov edi,71AF003Bh
71af0013 8b542410 mov edx,dword ptr [esp+10h]
71af0017 b918010000 mov ecx,118h
71af001c 33c0 xor eax,eax
71af001e f00fb15701 lock cmpxchg dword ptr [edi+1],edx
71af0023 7409 je 71af002e
71af0025 83c70e add edi,0Eh
71af0028 33c0 xor eax,eax
71af002a e2f2 loop 71af001e
71af002c eb04 jmp 71af0032
71af002e 897c2410 mov dword ptr [esp+10h],edi
71af0032 58 pop eax
71af0033 59 pop ecx
71af0034 5a pop edx
71af0035 5f pop edi
71af0036 e9a55c1101 jmp guard32!Exported+0x128b0 (72c05ce0)

and doing lm m guard32:

0:000> lm m guard32
start end module name
72bf0000 72c52000 guard32 (export symbols)
C:\Windows\SysWOW64\guard32.dll

Looking at the properties for C:\Windows\SysWOW64\guard32.dll, it is
owned by COMODO Internet Security. Voila!

[TP]

On Wed, Feb 11, 2015 at 9:48 AM, TP <win...@gmail.com> wrote:
> DrMemory-Windows-1.8.0-8.exe

Windows 7 SP1 64bit
WinDbg 6.11.0001.404 X86
DrMemory-Windows-1.8.0-8.exe
Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1

As a sanity check, I have now tried all my previous attempts using the
above configuration which does NOT include installing Comodo Internet
Security 8.1.

WinDbg now shows this for ntdll!NtClose (as expected):

ntdll!NtClose:
76edf9e0 b80c000000 mov eax,0Ch
76edf9e5 33c9 xor ecx,ecx
76edf9e7 8d542404 lea edx,[esp+4]
76edf9eb 64ff15c0000000 call dword ptr fs:[0C0h]
76edf9f2 83c404 add esp,4
76edf9f5 c20400 ret 4

And running:

drmemory -- handleleak.exe

I see in potential_errors.txt:

POTENTIAL ERRORS FOUND:
0 unique, 0 total potential unaddressable access(es)
0 unique, 0 total potential uninitialized access(es)
0 unique, 0 total potential invalid heap argument(s)
0 unique, 0 total potential GDI usage error(s)
1 unique, 50 total potential handle leak(s)
0 unique, 0 total potential warning(s)
0 unique, 0 total, 0 byte(s) of potential leak(s)
0 unique, 0 total, 0 byte(s) of potential possible leak(s)

So all is working as expected.

This also worked for the Release version of handleleak.exe.

An issue [1] was added as requested.

[1] https://github.com/DynamoRIO/drmemory/issues/1686

[Derek Bruening]

On Thu, Feb 19, 2015 at 2:47 PM, TP <win...@gmail.com> wrote:

So all is working as expected.

Good to hear.

An issue [1] was added as requested.

[1] https://github.com/DynamoRIO/drmemory/issues/1686

Thank you.