Read Me

By default LeakDetectControl will require this application to be registered.

Administrator password is: tarmopikaro

You need to restart application for registration to be enabled.

Licensing:

You're free to make any modification to given tools and dll's, as free of charge.
Author name (Tarmo Pikaro) should be mentioned in some about box if you decide to use this source code.
If you decide to improve or bugfix any issue, please commit your changes back to original svn repository.

For more information see URL: https://sourceforge.net/projects/diagnostic/


Few words about design of this code
-----------------------------------

1. Code base - STL
------------------

First of all - after project was more or less in mature state, I've reliazed that C++ was not the best 
tool I could use. I've understood that STL is quite heavy beast, whole memory leak analysis tool should 
be preferrably written in plain C.

By the time I've realized this - it's was bit late to re-write or restructure the code.

2. Breakpoints are not always working
-------------------------------------

In original code you can find mechanism of placing breakpoints and halting code in place where your 
memory leak is born. After fighting with some time with Visual studio (used 2012) - I've realized that 
it's not safe to place breakpoints in some places - Visual studio would either hung or crash. 
Especially mixed mode (Managed code) debugging can get your VS to hang.
So typically I've debugging using "native mode".

What to do when you want to know more information about your code execution ?

It's very tricky indeed, since even such simple operation as trace to debugger output window can 
cause hundred new allocations to be created. Only way to monitor health of your code is to use 
member variables - I guess.

3. Memory allocations made by diagnostic.dll
--------------------------------------------

When diagnostic is allocating memory on it's own it should not monitor itself. Unless you want 
to catch your own memory leaks, 
but then it's getting more into insane direction. (Rather difficult / non-trivial).

4. Everything slows down diagnostic performance
-----------------------------------------------

Any locking mechanism, any allocation, any trace - slows down diagnostic performance. Even thus 
it's currently in good shape - it still can be improved in future. Locking can cause dead locks 
with some of application. (Should be more or less fixed right now)


5. Memory API's being intercepted
--------------------------------------------

As first approach I've hooked HeapAlloc, HeapRealloc, HeapFree, but then I've noticed that this
was not sufficient -  memory leaks were looking like appearing from these function call - but 
process did not eat any memory. 

I've turned to ntdll, and hooked more system level API calls like RtlAllocateHeap, 
RtlReAllocateHeap, RtlDestroyHeap. Then I've managed to catch free of memory that was leaking 
out through higher level API.

But even after that I saw few memory allocation/freeing calls that disapper in depth of kernel 
- one of them was thread creation - using some undocumented allocation flag in API call. 
In future it makes sense to discuss this directly with Microsoft on how to intercept
windows and kernel so all memory allocations would be visible and tracked down. Windows should 
have build-in mechanism for memory leak analysis.

6. .PDB are very binary specific and very path specific
-------------------------------------------------------

If .pdb was compiled on one machine with path c:\project\test.pdb, then when placing on another 
machine - it must have same path -  otherwise .pdb does not gets loaded. Also any inconsistency 
in .pdb / .dll / .exe versioning leads to no symbol resolving situation.
This could be improved in future, but I haven't studied any deeper how .pdb loading could occur.

7. Stack trace determination is state of art
--------------------------------------------

Mixed / managed mode call stack determination API does not exists in internet. This code is very
first source which exists which can perform such thing. Unfortunately I've reliazed quite late 
that .NET memory (Garbage collector) is not hooked / not monitored by diagnostic - .NET is overall 
is coded somehow from zero, including memory management. What was a complete suprise is how complex
/ grotesque .NET is in overall. IL to native assembly compilation, run-time functions, not possible
to unload .dll assemblies, .net garbage collecting, memory leak detection for .NET. Maybe it makes 
sense to wait for .net 25th version - where everything will be fixed, assemblies can be unloaded 
from memory, call stack can be determined for mixed mode code, IL language sees to exist
and so on. :-)

I've added also .net improved call stack classes - like StackFrameEx, StackTraceEx - but these are 
rather experimental. The main problem as I see with call stack resolving is that .net resolves 
all function names immidiately, while diagnostic performs this afterwards - I suspect that .net 
is capable also disposing run-time code, but never hit against it anyway. .net makes it rather
difficult to unload assembly anyway.

For more ideas behind design / alternatives to design - I can recommend to browse following question 
threads:

    Fast capture stack trace on windows / 64-bit / mixed mode
    http://stackoverflow.com/questions/34501602/fast-capture-stack-trace-on-windows-64-bit-mixed-mode

    Resolve managed and native stack trace - which API to use?
    http://stackoverflow.com/questions/34733155/resolve-managed-and-native-stack-trace-which-api-to-use


8. Licensing software via serial number registration system
-----------------------------------------------------------

Typically when there is some licensing scheme in use - it most probably involves some
private information which is not published outside of organization, which owns particular
software. I've decided to collect everything into one tool. Most intresting part of story 
is that it's non-trivial to create serial number generator without knowing administrator 
password. For more ideas behind machinery - I can recommend to browse following question threads:

    Poor man serial number generation scheme
    http://stackoverflow.com/questions/35626119/poor-man-serial-number-generation-scheme

    Poor man serial number generation scheme, part 2
    http://stackoverflow.com/questions/35630096/poor-man-serial-number-generation-scheme-part-2



If you have any questions - feel free to contact me.

Tarmo Pikaro

e-mail: tapika@yahoo.com
skype:  tarmo_pikaro