DevPartner for Visual C++ BoundsChecker Suite is a suite of tightly integrated development features. DevPartner incorporates error detection, performance analysis, and coverage analysis, and includes a system comparison utility. DevPartner helps developers detect, diagnose, and resolve software bugs, maximize code performance, and ensure optimal code coverage and testing.
For purchase or upgrade issues, contact Compuware Sales, Monday through Friday, 8:00 AM to 8:00 PM EST:
For technical problems, from installation to troubleshooting, contact Compuware Technical Support:
Technical support is available as a Priority Support Service from 8:00 AM to 8:00 PM EST, Monday through Friday:
Problem reports should include:
This section presents known issues and technical notes for DevPartner. Click a feature name or category to view the list of issues and notes.
Suite-wide Issues
Coverage Analysis
Error Detection
Performance Analysis
Issues Specific to Visual Studio 2005 or to Visual Studio 2005 Team System
System Comparison
DevPartner's Modify option is not available through Control Panel > Add or Remove Programs on Vista systems. To modify a DevPartner installation on Vista systems, run DevPartner's installation program (setup.exe) and select the Modify option.
If you install Visual Studio 2005 after your DevPartner installation, follow this two-step process to integrate the two products:
The second step is required to integrate the DevPartner help system with the Microsoft help system.
Only one DevPartner feature1 or DevPartner product2 can monitor a particular application process at any given time. For example, if the DevPartner error detection feature is monitoring an executable file, you must wait until monitoring has finished before starting a fault simulation.
1Such as DevPartner error detection or performance
analysis
2Such as DevPartner Fault Simulator or DevPartner
SecurityChecker
Systems with the Data Execution Prevention (DEP) setting configured as
/NoExecute=Always On and the CPU's Execute Disable bit enabled
might prevent DevPartner from loading into Visual Studio.
See article number 875352 in the Microsoft Knowledge Base for a detailed description of the Data Execution Prevention feature.
System-wide DEP is set in the BOOT.INI file using the
/NOEXECUTE option on the system boot partition. By default this is
set to OptIn, which specifies that DEP is only enabled for
essential Windows programs and services.
Setting this to AlwaysOn causes the DevPartner installation to
fail, and if the setting is changed to AlwaysOn after installation
it will cause the DevPartner Visual Studio package to fail to load into Visual
Studio.
If you set DEP to OptOut, be sure to include the Visual Studio
executables (DEVENV.EXE for Visual Studio 2003 and 2005,
MSDEV.EXE for Visual Studio 6) in the list of programs and services
that are not to run with DEP.
The integration to the DevPartner Fault Simulator product does not work with DevPartner Studio 8.2.1. Users of Fault Simulator integration should use DevPartner Studio 8.2.
Installing Fault Simulator 1.5 after installing DevPartner, then uninstalling Fault Simulator, causes a licensing failure when attempting to run DevPartner.
To correct this problem, after uninstalling Fault Simulator:
During installation or removal of DevPartner, an MSI.EXE error message might display stating that the application has encountered an error or has referenced memory it cannot read. Click Ok and ignore this error. The install/uninstall will continue without error.
Buffer overrun protection, a feature of many antivirus packages, can cause intermittent crashes when profiling Internet Explorer and IIS. Errors such as the following may occur:
"The application failed to initialize properly (0xc0000005) Click Ok to terminate."
If you have anti-virus installed and encounter these errors, turn off your anti-virus package's buffer overrun protection feature or contact your anti-virus vendor for updated software.
If you install Microsoft Visual Studio 2005 Service Pack 1, you must reboot your machine after installing the service pack.
If you are attempting to install Microsoft Visual Studio 2005 Service Pack 1 on Windows Server 2003, be aware of the issues described in Microsoft Knowledge Base article #925336.
On Vista systems with UAC enabled, if you run Visual Studio 2005 without Administrative privileges,
the Mach5 driver required for performance profiling is not started. Performance analysis will
provide inaccurate data. To correct this condition,
run Visual Studio 2005 as an administrator, as suggested by Microsoft, or manually start the Mach5
driver with the net start mach5 command.
There is a known issue with displaying data collected for static initialization of member fields of partial classes in which a constructor is implemented in a different source file than the statically initialized fields. In these cases the source view will show no data for the static member field initialization. This is because the data is attributed to the constructor of the partial class and not the assignment statement for the static initialization of the field. If a source file only contains statically initialized member fields for a class, the source file will not be shown in the list of source files for the module in the results.
When running Error Detection, you may encounter one of the following issues:
Visit the DevPartner Support Knowledge Base on Frontline (http://frontline.compuware.com/apps/kb/) and search for Team Foundation Server for a workaround.
When you build the BugBench sample on Vista, you must have Administrative privileges. Building the sample generates a COM DLL that must be registered. Vista will not allow the DLL to be registered if you lack sufficient privileges.
To ensure successful monitoring of your application when using Wait for Process under the standalone version of Error Detection, the target names and paths must exactly match what you specified to Error Detection. If you use an intermediary step that somehow changes the target names or paths, Error Detection may not recognize that your application has launched. For example, if you select an executable (C:\MyApplications\foo.exe) as your target, select Wait for Process, and then launch an intermediary application that changes the fully qualified names to short names and launches C:\MyAppl~1\foo.exe, Error Detection will not recognize that your application has been launched.
You may discover Error Detection is not returning symbol information. This can be caused by having your symbol paths defined at the solution level rather than the project level. Define your symbol paths under Project Settings.
If you attempt to open a legacy solution file, Visual Studio 2005 may display
the following error message: The selected file is a solution file, but appears to be
corrupted and cannot be opened. The problem is due to an obsolete entry in the
solution file written by an earlier version of DevPartner. You can safely
remove this entry using Notepad. To remove the entry:
GlobalSection(DevPartner Solution Properties) =
postSolution
EndGlobalSection
The first time that an application is run with Error Detection, you may see a dialog from Microsoft Internet Symbol Store detailing their Terms of Use. You must accept the Terms of Use to continue, even if you have previously accepted these Terms of Use when running a different program that also required Microsoft symbols.
In some cases, when you profile custom Windows services while logged in through Terminal Services, you may not get session files. If this occurs on your system, you may be able to save the session data by specifying the full path and filename for the session file. For example:
DPAnalysis.exe /cov /output c:\temp\MyService.dpcov /s
MyService
Note: This may not work in all cases.
When using NMCL or NMLINK directly from the Command Line, you must add the
directory containing these utilities to your path. For example, if you installed
the product into the default directory, add the following directory to your
path:
C:\Program Files\Common
Files\Compuware\NMShared
The linker option /pdbtype:sept is no longer supported by the Microsoft debug file access routines. By default, projects created by the Visual C 6 Integrated Development Environment set this option. You can remove this switch with no other impact on your project, and then continue with compilation and re-linking. Unfortunately, Error Detection cannot detect whether this linker option was used to create the module. If /pdbtype:sept was set, Error Detection will report memory leaks in the C Runtime library that are normally suppressed.
There are two options:
If you are building outside of the Integrated Development Environment, you will only see this issue if you explicitly added /pdbtype:sept to your makefile(s). If a makefile includes the /pdbtype:sept text, you should edit the makefile and remove it.
There are two situations in which DCOM or COM-based applications or components try to run under the restrictions of the aspnet account. By default, when a DCOM or COM application or component is launched from within an ASP.NET enabled Web page, it will run in the context of the aspnet account. For security reasons, the aspnet account is a restricted account (it is a member of the Users group and has equivalent privileges). In this situation your COM component will not have the security privileges required for Error Detection to function properly. To work around this issue, you must configure your DCOM or COM application or component to execute within the context of the interactive user (via dcomcnfg.exe).
To configure your DCOM or COM application or component to run under the context of the interactive user:
- Open a command prompt and run dcomcnfg.exe.
- Expand Component Services -> Computers -> My Computer -> DCom Config.
- Right-click on your COM component, and select Properties.
- Select the Identity tab.
- Ensure that you have selected The interactive user.
- Click OK.
Error Detection will collect data properly the next time the DCOM or COM application or component is launched.
As it ships, the source path for BugBench is configured for Visual Studio .NET 2003. If you run BugBench examples with Visual Studio 2005, you need to modify the source path in the BugBench settings file to point to the directories for the sources shipped with Visual Studio 2005.
DevPartner Error Detection may fail to analyze a service. A common cause is one (or more) of the directories used to monitor the process is not writable to the process being created. The following directories must be writable:
- The TMP and TEMP environment variables must reference a directory that is writable to the process. If you have configured your service to run the LOCAL_SYSTEM context, you will need to assign these environment variables system wide.
- The service must have write access to the NLB File directory.
- The service may require write access to the working directory.
DevPartner Error Detection may fail to stop in the debugger when the Program Error Detected dialog box is dismissed with the Debug button. When you dismiss the Program Error Detected dialog box with the Debug button, Error Detection puts a temporary breakpoint in your application at the start of the first line after the error. The breakpoint is automatically removed when the application stops in the debugger. If your application has an exception handler that catches the breakpoint exception and continues execution, the debugger will not get a chance to catch the breakpoint and stop the application for you.
If you attempt to run an application with Error Detection in a directory to which you do not have write access, you may receive an error similar to the following:
UserAllocatorsError: An error was discovered when processing the
UserAllocators.dat file. Failed to create UserAllocators.log file
Error:0x00000005
You can control the directory that the UserAllocators file is written to by setting the NLB File Directory on the Data Collection settings page and checking the Generate NLB files dynamically check-box.
lParam entries
that can be associated with controls or control items. This may result in
erroneous leak leaving scope errors reported when using FinalCheck
instrumentation. In some cases, CPU time attributable to the expression part
of a For loop can be incorrectly attributed to the body of the
For loop. This can occur in loops formatted so that the
initializers, expression, and iterators appear on a single line, as in the
example below.
using System;
public class ForLoopTest
{
public static void Main()
{
for (int i=1; i<=5; i++)
Console.WriteLine(i);
}
}
If the body of the For loop appears to be consuming excessive
CPU time, reformat your code so the initializers, expression, and iterators
appear on separate lines, as shown below.
{
for (int i=1;
i<=5;
i++)
Console.WriteLine(i);
}
If you attempt to run a coverage analysis session immediately after running a performance analysis session on an ASP .NET Application running under IIS 6.0, Visual Studio may stop responding.
To recover from this situation:
iisreset in the Open
field.
There are two ways to avoid this situation:
iisreset before running a
different type of session.
If Performance Analysis runs too slowly on a supported low-end PC (for example, a 733 MHz Pentium III), you can speed up performance analysis sessions by changing the processor scheduling to provide equal processing priority for background services.
When running coverage or performance analysis, Visual Studio may become unresponsive and then display the following error:
Could not restart Internet Information Server (code %d).
(In the message above, %d represents an internal error code. In the context of this issue, you can ignore this code.)
If this occurs several times, make sure that Internet Information Server is running. If it is not running, exclude system DLLs and try again.
If the problem persists, use DPAnalysis.exe from the command
line to analyze the application. Run DPAnalysis.exe through a
configuration file that excludes inetinfo.
For more information, see the topic Using DPAnalysis.exe in the DevPartner online help or Appendix C of the Understanding DevPartner manual.
On systems with both DevPartner Fault Simulator 1.5 and DevPartner installed, you can run Fault Simulator and Coverage Analysis sessions simultaneously. (To do this, choose Fault Simulator > Start with Fault Simulator and Coverage Analysis or Fault Simulator > Start Without Debugging with Fault Simulator and Coverage Analysis.)
In some cases, when running Fault Simulator and Coverage Analysis sessions together on a managed standalone Windows application, the DevPartner Session Control toolbar may be unavailable. This will prevent you from using the Stop Recording, Take snapshot, and Clear all recorded data functions during the session.
If your Coverage analysis requires use of the Session Control toolbar functions, try one of the following workarounds:
When using DevPartner with a localized version of Visual Studio Team System, in which the name of the WorkItemType Bug has been localized to a string other than 'Bug', DevPartner will not be able create and submit bugs to the Team Project.
If you open a solution that contains managed and unmanaged projects, the following commands in the DevPartner menu are unavailable:
There are two approaches to analyzing mixed code solutions.
To analyze the unmanaged code from within Visual Studio:
To analyze the managed and unmanaged projects together:
In Visual Studio 2005, you can create a zero impact project (ZIP) by disabling the Save new projects when created option in the Tools > Options > Projects and Solutions > General options page. However, disabling this option prevents DevPartner from creating a virtual folder for the session file in Solution Explorer or storing the session results in that folder. For best results in collecting data from your project:
If you launch a session without saving the project, click Save when Visual Studio presents the message "The current project must be saved before adding a project". Visual Studio will rename the project and store it in Solution Explorer. Although the session file is created in this scenario, it will contain references to the temporary locations of the project source code and executable modules, as well as the temporary project name. We do not recommend running the DevPartner on Visual Studio 2005 "ZIP" projects.
By default, the System Comparison service is set to start automatically. The service takes a daily snapshot of your machine to facilitate system comparisons. The service runs at minimum priority, but it does consume some system resources for several minutes while it runs. If use of system resources is a concern, you can set the startup type to manual, but you will lose the functionality of having snapshots created automatically.
If you compare a snapshot taken with a previous version of the System Comparison utility with a snapshot taken with DevPartner 8.1.1 or later, System Comparison displays a message indicating that the plug-in schema is not compatible. The data recorded in snapshots has changed, making it impossible to create a meaningful comparison of old and new snapshots.
In addition, if you have created custom plug-ins you will have to rebuild them against the current version of the plug-in schema.
System Comparison now checks for additional settings when comparing systems:
If you compare a snapshot taken with a previous version of the System Comparison utility with a snapshot taken with the DevPartner Studio 8.2 or later version, these settings will be listed as missing from the older snapshot.
Error Detection will still report some Leaks and Errors, even if all Modules are OFF under the Error Detection Settings, because:
If you install DevPartner Fault Simulator SE and you use a Fault Simulator feature that requires a license, that license checkout will cause the license timeout policy to be overridden.
To perform coverage analysis and error detection in Visual C 6, you must enable the Error Detection option on the DevPartner menu or toolbar.
DevPartner for Visual C++ BoundsChecker Suite Known Issues
Copyright © 2007, Compuware Corporation
08/09/2007 03:34 PM