Method and system for categorizing failures of a program module

• US 20040250170A1
• Filed: 06/28/2004
• Published: 12/09/2004
• Est. Priority Date: 05/15/2000
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Mensching, Rob M., Glerum, Kirk A., Ruhlen, Matthew J., LeVine, Eric A., Walker, Charles S.
• Granted Patent: US 7,219,266 B2
• Time in Patent Office: Days
• US Class Current: 714/38
• CPC Class Codes: G06F 11/0748 in a remote unit communicating with a single-box computer node experiencing an error/fault remote testing G06F11/2294
• CPC Class Codes: G06F 11/0775 Content or structure details of the error report, e.g. specific table structure, specific error fields

Abstract

A method for categorizing information regarding a failure in an application program module. The failure may be a crash, a set-up failure or an assert. For a crash, a name of an executable module where the crash occurred in the application program module, a version number of the executable module, a name of a module containing an instruction causing the crash, a version number of the module and an offset into the module with the crashing instruction are determined. This bucket information is then transmitted to a repository for storage in a database. The database may be examined to determine fixes for the bug that caused the crash.

Claims

1-20. -20. (canceled)

21. A method for categorizing information regarding a crash in an application program module, the method comprising the steps of:

determining data related to the crash in the application program module;

placing the crash related data into a bucket;

transmitting the bucket to a repository for storage;

comparing the bucket to a bucket entry in the repository to determine whether the bucket matches the bucket entry and, if so, then increasing the hit count for the bucket entry; and

if the bucket does not match the bucket entry in the repository, then adding the bucket as a new bucket entry in the repository.

22. The method of claim 21, wherein the data related to the crash in the application program module comprise:

a name of an executable module where the crash occurred in the application program module;

a version number of the executable module;

a name of a module containing an instruction causing the crash;

a version number of the module; and

an offset into the module with the crashing instruction.

23. The method of claim 21 further comprising the step of determining whether the repository requires additional data regarding the crash and, if so, then requesting and receiving additional data from the application program module.

24. The method of claim 23 wherein the additional data is transmitted to the repository as a .cab file.

25. The method of claim 24 wherein the additional data comprises a minidump.

26. The method of claim 24 further comprising the step of examining the .cab file to determine a fix for a bug that caused the crash.

27. The method of claim 24 wherein the bucket entry comprises the bucket, a response entry, and a hits entry.

28. The method of claim 27 further comprising the step of comparing the bucket to a PDB to determine a symbol entry and a source entry and adding the symbol entry and source entry to the bucket entry.

29. The method of claim 25, wherein the additional data further comprises secondary data comprising a plurality of registry keys, files, file versions, documents and WQL query results.

30. A computer readable medium having instructions stored thereon for causing a computer to perform a method categorizing information regarding a crash in an application program module, the method comprising the steps of:

determining data related to the crash in the application program module;

placing the crash related data into a bucket;

transmitting the bucket to a repository for storage;

comparing the bucket to a bucket entry in the repository to determine whether the bucket matches the bucket entry and, if so, then increasing the hit count for the bucket entry;

if the bucket does not match the bucket entry in the repository, then adding the bucket as a new bucket entry in the repository; and

determining whether the repository requires additional data regarding the crash and, if so, then requesting and receiving additional data from the application program module.

31. The computer-readable medium of claim 30 wherein the additional data is transmitted to the repository as a .cab file.

32. The computer-readable medium of claim 30 wherein the additional data comprises a minidump.

33. The computer-readable medium of claim 31 further comprising the step of examining the .cab file to determine a fix for a bug that caused the crash.

34. The computer-readable medium of claim 30 wherein the bucket entry comprises the bucket, a response entry, and a hits entry.

35. The computer-readable medium of claim 34 further comprising the step of comparing the bucket to a PDB to determine a symbol entry and a source entry and adding the symbol entry and source entry to the bucket entry.

36. The computer-readable medium of claim 32, wherein the additional data further comprises secondary data comprising a plurality of registry keys, files, file versions, documents and WQL query results.