15,888,527 members
Sign in
Sign in
Email
Password
Forgot your password?
Sign in with
home
articles
Browse Topics
>
Latest Articles
Top Articles
Posting/Update Guidelines
Article Help Forum
Submit an article or tip
Import GitHub Project
Import your Blog
quick answers
Q&A
Ask a Question
View Unanswered Questions
View All Questions
View C# questions
View C++ questions
View Javascript questions
View Visual Basic questions
View Python questions
discussions
forums
CodeProject.AI Server
All Message Boards...
Application Lifecycle
>
Running a Business
Sales / Marketing
Collaboration / Beta Testing
Work Issues
Design and Architecture
Artificial Intelligence
ASP.NET
JavaScript
Internet of Things
C / C++ / MFC
>
ATL / WTL / STL
Managed C++/CLI
C#
Free Tools
Objective-C and Swift
Database
Hardware & Devices
>
System Admin
Hosting and Servers
Java
Linux Programming
Python
.NET (Core and Framework)
Android
iOS
Mobile
WPF
Visual Basic
Web Development
Site Bugs / Suggestions
Spam and Abuse Watch
features
features
Competitions
News
The Insider Newsletter
The Daily Build Newsletter
Newsletter archive
Surveys
CodeProject Stuff
community
lounge
Who's Who
Most Valuable Professionals
The Lounge
The CodeProject Blog
Where I Am: Member Photos
The Insider News
The Weird & The Wonderful
help
?
What is 'CodeProject'?
General FAQ
Ask a Question
Bugs and Suggestions
Article Help Forum
About Us
Search within:
Articles
Quick Answers
Messages
Comments by Octopod (Top 5 by date)
Octopod
27-Jan-12 5:13am
View
Deleted
I think you're facing to the same troubles we can encounter with VS2008 or other versions. Some applications are more unstable with LiveHeap hooked on them. I'm not sure this is linked to the version of VS.
Maybe you could retry without attaching VS2010 debuggee on your application (Ctrl+F5) ?
Octopod
27-Jan-12 5:08am
View
Deleted
But you can't check the memory leaks of a release builds with the _CrtDumpMemoryLeaks trick. You can't always use debug build, for example when doing a diagnostic in production context. In addition, as you point, release builds can have different behavior.
Coming to the thrid party code, the callstack shows you the code that make call to the third party, which can lead you to understanding a wrong use of this third party code. And sometimes you have the .pdb of release third party code, revealing the full callstack (check Symbols servers, http://msdn.microsoft.com/en-us/library/windows/desktop/ee416588(v=vs.85).aspx#ID4EUG, it might be of interest).
About the VS2010 I think you're facing to the same troubles we can encounter with VS2008 or other versions. Some applications are more unstable with LiveHeap hooked on them. I'm not sure this is linked to the version of VS.
Octopod
27-Jan-12 3:56am
View
Deleted
Reason for my vote of 2
Thank you for this hint for who don't know it already. The downside is that with _CrtDumpMemoryLeaks, only the allocations made by your code will be catched and reported. By using LiveHeap, you can catch all allocations, even those that are done in release code and in third party code.
Octopod
27-Jul-11 4:32am
View
Deleted
You should then try to put breakpoints to embrace specific functions rather than the all program, and see if it helps. Or you can also, without breakpoints, starting LiveHeap before doing a specific action while your application is already started (like opening a file in your application, then closing it, to get leaks for file opening).
Octopod
14-Jul-11 11:52am
View
Deleted
LiveHeap gives you a real time view of all your allocations. The trick of using it between the beginning and the end of your application execution allow to gather memory leaks. That's all.
ApplicationVerifier is a front end on gflags, which trigger a set of checks that are embedded into the windows kernel (adding guard pages to allocations, collecting stack trace for future use in WindDbg, checking API calls, etc.).
I would say that both are to be used for tracking leaks, bugs & defects. Different tools, different purposes.