Mismatched Array/New Delete

This is a example program which shows a common coding error, that I have seen quite a bit - mismatching scalar vs vector new/delete.

Raymond's blog entry has more detail about what can happen when you do this by mistake. To make a long story short - memory leak or heap corruption.

Here is an example program which shows these errors:

#include
#include
#include


int main()
{
char *tmpArray = new char[17];
strcpy(tmpArray,"This is tmpArray");
printf("tmpArray=%s\n",tmpArray);

char *charArray=new char[18];
strcpy(charArray,"This is charArray");
printf("charArray=%s\n",charArray);
delete charArray;

char * character = new char;
*character = 'a';
printf("character=%c\n",*character);
delete [] character;

printf("tmpArray=%s\n",tmpArray);
free(tmpArray);

printf("Press Enter to continue");
int a = getchar();

}

Winqual Microsoft Product Feedback Mapping Tool

Here is a post for the "average" software developer signing up for Microsoft Winqual and mapping their products. The documentation available isn't every helpful, and it's easy to make mistakes when first mapping your product, thus ending up with too many useless/irrelevant data (at least that's the mistake I made! :) )

Winqual is the great service provided by Microsoft for ISVs to get access to Dr Watson and WER (Windows Error Reporting) data, such that you can improve your/your company’s software quality. This is a bigger deal in Vista, since the reporting loop is now closed, and you can provide feedback about the reported issue to the end-user via the Winqual service.

By an "average" software developer, I mean a vendor shipping software that is for the end-user in mind vs perhaps a vendor shipping a library or component used by other software developers.

That end-user product usually has dependencies on various 3rd party dlls as well as the standard Microsoft dlls. The trick here is to get feedback just on the software you own and are responsible for, while excluding getting data from software that you don’t support. This would mean you would want to know about all crashes in your .exe, whether it was executing your code, or in a 3rd party library or MSFT library (often the case), whose root cause is statistically likely to be in your code anyways.

Either way, even if the fault lies in a 3rd party component, your company is responsible for following up with the vendor to resolve the issue for your end customer. Contrast this with specifically not wanted to get events from every product (only yours) that uses that 3rd party library (such as a regex) library.

The mapping can be done in many ways, but I would recommend for most average ISV software companies that the mapping is done on a per Product/Version basis.

I.e. Separate mappings for

Product A V1.0
Product A V2.0
ProductB V1.0
ProductB V1.1 (only changed binaries mapped)

It also depends on how you deliver SP/Hotfix updates; be it whether they are a complete redelivery of the product, a rebuild, or only the incremental binaries. For example, Product A might use a SP installer with only incremental binaries (only updated binaries changed).

In such a case I tend to map only the changed binaries, as I want failures only associated with the SP to show up under that product, and any failures in the base version to show up in the base version. In other words, customer runs Product A V1.1 (SP) but has a crash in a component that didn't get upgraded. This would be reported under Product V1.0.

So on to the mapping itself. The mapping tool is fairly self explanatory, you start by filling out your Product Files Directory Path, Name and Version.
So you might map something like:
Directory Path: C:\Program Files\ProductA V1.0
Name: ProductA
Version: 1.0

Since a lot of products use/include Microsoft dlls, you may get warnings that those dlls will be excluded. This is normal, and is Microsoft ensuring that you don’t get events from virtually every piece of Windows software on the planet. Note: this doesn’t mean you won’t get events from where you crashed in kernel32.dll, but was in ProductA.exe

Next comes the mapping itself, which is what you want to be most careful on. The safest method is to ONLY select your .exe(s). For example, let us pretend we are the Mozilla foundation wanting to get reports of crashes/hangs with Firefox. Note: Firefox happens to use its own crash reporting mechanism – TalkBack, but we can’t all be so lucky or have the infrastructure in place for this.

Here is the open source Firefox browser mapped with only .exe’s I know to be from this Firefox build selected.



Here is another screenshot showing more .dlls selected, as it seems likely these are directly used by this build of Firefox (the Link Date and Binary Version is the clue). You may want to include these dll’s as a sort of catch-all, so that you don’t miss any events. They should be associated with just this version of the product, but may include other versions, but at least are associated with Firefox itself. Sort by Binary Version, Link Data, Product Name and Directory Path to quickly isolate which binaries your company is responsible for.



Once you are all set you can upload the resulting XML file to Winqual. The end result should be that you are getting appropriate and useful data that you can use to fix issues and improve software quality. If you notice you are getting events from other software vendors, you can always manually remove the troublesome mappings, or delete & re-upload the mapping file.

Handle Leak Tracking with WinDbg

Here is a short process for isolating handle leak issues for Windows processes using Windbg and the !htrace extension. This requires that you can reproduce the handle leak consistently, and take periodic handle snapshots to where you are leaking.

Notice, similar to memory leaks, it will be normal for some handles to be created during the diff process w/o being closed. You are looking for the large increase of handles that were opened w/o being closed.

1. Ensure you have PDBs generated for as many as the exes, dlls, ocxs as possible when debugging.
2. Start Debugging Tools for Windows -> WinDbg
3. Do Edit->Open/Close Log File. Enter log file path/name and hit ok. (If no path is specified, will be saved under the Debugging Tools for Windows folder)
4. Do File -> Attach to a Process
5. Choose the process, make sure noninvasive is not checked (default)
6. Debugger should now be attached to the process and the process paused
7. In the command window, type '!htrace -enable' to enable handle tracing
8. Cmd Window: Type '!handle' to get each handles id and type, and list of handle counts
9. Cmd Window: Type '!htrace -diff' to show the differences between the last '!htrace -snapshot' and the current handles. Note the first time this is run, diffs will show empty
10. Cmd Window: Type '!htrace -snapshot' to take a new snapshot for use in the next round of testing
11. Cmd Window: Type 'g' to get the process running again
12. Test the application again, monitoring perfmon or task manager for an increase in handles, once a suitable increase is present, continue
13. Goto Debug -> Break
14. Repeat steps 8-13 as many times as necessary in order to get appropriate handle data
15. Do Edit->Open/Close Log File & select the 'Close Open Log File' button.

Once this is complete, in the !htrace diff output, you should see the stack trace of your code that most likely leaked the handle.

Hello!

I just wanted to start off this first post by giving a short introduction.

My name is Ivan Berg, and I am Software Engineer at Avaya in the R&D Solutions Support arena.

Avaya is a telecommunications vendor producing corporate telephone systems and software for 90% of the Fortune 500 companies. We just went from a Fortune 500 ourselves, to a private company, so it should be an exciting time for us.

So I have had the great opportunity to work on interesting issues (and some not :) ) Technology is amazingly complicated, and sometimes I wonder how much of it works at all!

Expect posts from time to time covering my experiences troubleshooting bugs in software, or tweaking designs and software.

I regularly use the following: Windbg, SysInternals suite, Text Parsing Tools (more on this later), Desktop Search (essential for quickly finding knowledge and digging through source), Application Verifier, etc, etc.

I am a big fan of the following technical troubleshooting blogs, and a lot more....

http://blogs.technet.com/markrussinovich/ - Always great posts from Mark. I may just have to "borrow" the "The case of the....." format, which is pretty slick

http://www.wintellect.com/cs/blogs/jrobbins/default.aspx
I mean, John did write one of few available books on Windows debugging

http://blogs.msdn.com/tess/default.aspx
Great posts from Tess! Tess seems to have a position similar to mine, albeit supporting different products. Always fun to in the front lines of customer issues!

Anyways, that's all for now