Hello everyone,

Just recently I ran into one of those nasty memory bugs that needs digging for days. After wrestling with Visual Studio and Windows for days I finally gave in and switched to Linux for Valgrind. I've been using it to trace use-after-free errors for years. The equivalent on macOS is clang's Address Sanitizer which is present in XCode.

Is there such a thing for Visual Studio? I've tried the Memory Error tool from Intel Inspector but it lacks the tracing that Valgrind and ASAN provide: pinpointing the exact place a pointer was set free , not just when it's used after.

Is there any hope? Thanks.

Its called “Application verifier” and is eigether a separate download or a part of the windows debugging kit:

https://docs.microsoft.com/en-us/security-risk-detection/concepts/application-verifier

Its much more memory-hungry thatn asan though (effectively places each allocation at a page-boundary), but also a bit more pontent from my experience.

I am familiar with it, but as far as I recall it does not perform the origins tracking part. Am I wrong here and just missed some settings?

Oh, sorry, missed the part abort finding where the allocation originally came from. I don't think AV has it, haven't needed it personally though so maybe its just hidden - couldn't tell, sry.

I expressed myself poorly here, it's not the origins of the allocation I care much about, but rather the place of it's deletion. That's usually the place the removal information is not passed along the interested parties and dangling pointers start wrecking their havoc. I'll dig some more into Application Verifier but as far as I recall VS would break into the error access place while running it with it active, you would still have to do the work of tracing the deletion point.

dotnka said:
I expressed myself poorly here, it's not the origins of the allocation I care much about, but rather the place of it's deletion. That's usually the place the removal information is not passed along the interested parties and dangling pointers start wrecking their havoc. I'll dig some more into Application Verifier but as far as I recall VS would break into the error access place while running it with it active, you would still have to do the work of tracing the deletion point.

No sorry, it was me using the wrong word here, I understood what you meant though. I could offer you some alternative tips/help in locating the issue if you were to show some more details though. Wondering why, though I had a number of access-after-deletion I never really needed to have that information when I think back, so maybe there's something else that could help

Are you managing your memory by your own or have an SDK under the seat?

Don't know your programming language but if you compile everyting on your own and have access to it, just override new/delete (if used) or malloc/ free (if used) and grab a stack-trace or force using an own allocator and have that tracking down everything helped me in the past to locate those bugs easily.

I wrote a small profiler extension for my code that collects all information as fast as possible and sends them as packed data slices via UDP to a receiver

It's all C++, and no SDK. Sounds like a good plan actually, emulating a smart-pointer infrastructure with notifications and validity checks for during debug.

Separately I eventually got to this - https://www.parasoft.com/products/insure but their price point is … let's say prohibitive.

You can install WSL2 and compile your project with Clang/GCC like normal. I assume it will just work. Otherwise, there is always virtualization or dual-booting. Personally I develop on Linux and occasionally switch to Windows to build a .exe for testers.

As for Windows itself. I've read before the MSVC had it. Turns out they do: https://devblogs.microsoft.com/cppblog/addresssanitizer-asan-for-windows-with-msvc/​​​

You can also build with Clang in MSVC.

If you want a simple thing to see where allocations come from; or a list of allocated memory, it's built into the CRT:

https://docs.microsoft.com/en-us/visualstudio/debugger/finding-memory-leaks-using-the-crt-library?view=vs-2019