Memory Corruption

Application Verifier

Here’s a link to a tool that can help track down problem in applications, such as the memory corruption issue in V4, and a whole lot more.

http://www.microsoft.com/technet…xp.mspx

It’s a pretty big download. I don’t suggest anyone get this, except those doing development themselves, then I suggest they get it ASAP. Flavio has it and I know he’s been using it. It’s not an end all to finding problems. Anyway, if you do get it keep in mind that the info you find may or may not be helpful to Flavio and may just add mud to the flood of complaints. We don’t need folks running this and complaining that n-Tracks it crashing when it runs. That’s what it’s suppose to do. It will also suck up the CPU and memory, depending on what options are selects. To be useful one needs to know what each option checks and what to expect. Blindly turning them on isn’t that helpful.

Here’s what happens on my machine. I suspect this is at the root of some problems, but this doesn’t expose THE problem. It simply gets near the time it happens.

Scenario:
–Turn on PageHeap foe ntrack.exe in AppVerif
–Run ntrack.exe
–Open and existing song file

The pop happens when the song is loading, dev studio automatically runs and shows this stuff.

Complete screen shot of the crash in MS Dev Studio (big picture - 235k): http://downloads.phootoons.com/ntrack_pageheap.jpg

Debugger Text Output: http://downloads.phootoons.com/ntrack_pageheap_output.jpg
This shows that the last thing called before the pop was loading VST plugin. I removed all VST plugins later and the pop happened in the same place. The pop is actually happening during the NEXT call, whatever that is. It’s unfortunately not displayed in the output.

Debugger Stack Trace: http://downloads.phootoons.com/ntrack_pageheap_stack.jpg
This shows the actually last bit of code that was called before the pop. It’s in msvsr71.dll. It’s a call to HeapAlloc with a very large size request. This is probably a good clue, but could be a red herring.

My WAG is that this call is either (1) failing and returning an error code or (2) it’s succeeding and the pointer the allocated memory block is getting assigned to is not a valid pointer. Uninitialized variables can cause this, or a lack of error checking in the code. Check for null, which doesn’t appear to be the case, or check for specific error code, which also doesn’t appear to the case but I don’t know what the error codes actual values in hex are and I can’t see the value that is returned.

Regardless, whatever is returned is getting used as a valid pointer to valid memory in the very next call, and it’s not. That’s why AppVerif pops when the PageHeap option is on.

It’s also possible that the code causing the error isn’t in n-Tracks at all, but in some dll n-Tracks has loaded. If that’s the case then Flavio can’t fix it in ntrack.exe, but needs to contact the owner of the dll and get them to fix it there. It could be in a driver, video or audio, or anything else for that matter.