DevPartner Studio 8.2.1 Professional Edition is a suite of tightly integrated development features. DevPartner Studio incorporates code reviewing, error detection, two kinds of performance analysis, coverage analysis, and a memory analysis feature all integrated into Visual Studio, as well as a system comparison utility. DevPartner Studio helps developers detect, diagnose, and resolve software bugs, maximize code performance, improve memory usage, 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 Studio. Click a feature name or category to view the list of issues.
Suite-wide Issues
Code Review
Coverage Analysis
Error Detection
Memory Analysis
Performance Analysis
Performance Expert
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.
After running a code review in Visual Studio 2005, session files for any DevPartner Studio tool cannot be individually deleted from within the Visual Studio Integrated Development Environment. As a workaround, delete the DevPartner Studio folder in the solution explorer window.
If you install Visual Studio 2005 after your DevPartner Studio installation, follow this two-step process to integrate the two products:
The second step is required to integrate the DevPartner Studio help system with the Microsoft help system.
Only one DevPartner Studio feature1 or DevPartner product2 can monitor a particular application process at any given time. For example, if the DevPartner Studio error detection feature is monitoring an executable file, you must wait until the monitoring operation has finished before starting a fault simulation.
1Such as DevPartner Studio error detection, performance analysis, or
memory 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 Studio 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 Studio 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 Studio, then uninstalling Fault Simulator, causes a licensing failure when attempting to run DevPartner Studio.
To correct this problem, after uninstalling Fault Simulator:
During installation or removal of DevPartner Studio, 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 Expert will be
non-functional, and 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 Studio 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.
When a Visual Basic 6.0 component is loaded into a Visual Studio 2005 Integrated Development Environment process and the user adds a solution to Team Foundation Server Source Control, the Integrated Development Environment will essentially lock up. Since code review uses some Visual Basic 6.0 components, this problem may occur on systems on which DevPartner Studio is loaded.
Microsoft has developed a hotfix for this problem. Visit http://support.microsoft.com/?kbid=922989 for information about this hotfix.
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 Studio. 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. If the module is being instrumented for Error Detection, the instrumentation process temporarily removes this linker option and resolves potential issues. However, if you are not instrumenting the module, Error Detection cannot detect whether this linker option was used to create the module, and you may encounter problems.
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.
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. If you attempt to collect Memory Leaks or RAM Footprint data for a memory analysis session started under the Visual Studio .NET debugger, garbage collection roots will appear as "unidentified GC roots" in the session data. To enable DevPartner Studio to properly identify most garbage collection roots in Memory Leaks or RAM Footprint sessions, start memory analysis for your application without debugging.
Running Memory Analysis or Performance Expert on Web applications (such as those created with a wizard in Visual Studio 2005) generates a small amount of spurious data. Regardless of the number of lines in the source file, the spurious data appears on lines with numbers greater than 912,304, and may be safely ignored.
In Memory Analysis session files for J# applications, the Object Reference graph may show two root references for some String objects, due to the way the .NET Framework handles internal system String objects. In such cases, the graph shows one root reference from an object array and an independent reference from a String array. In contrast, the Object Reference graph for a C# application typically shows a single root reference to the String objects.
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, memory analysis, or Performance Expert 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.
You may be unable to merge coverage session files for ASP.NET 2.0 applications.
DevPartner Studio can only merge coverage session files from the same build of your ASP.NET 2.0 application. With ASP.NET 2.0, the executable name changes every time you rebuild the solution.
To avoid this problem, run all coverage sessions that you intend to merge without rebuilding your application between sessions.
If code coverage is enabled and you use Fault Simulator to add a source-based .NET fault where the code construction includes compound or nested source statements on a single line, Fault Simulator might be unable to properly evaluate the designated method call. As a result, Fault Simulator might not fire the corresponding fault as expected during the fault simulation.
As a workaround, break out the source statement into multiple lines of code. Consider the following examples:
Example 1:
Change from this construction:
DateTime[] dates = new DateTime[]{
new DateTime(2000, 1, 1),
new DateTime(2001, 1, 1, 0, 0, 0)};
To this construction:
DateTime dt1 = new DateTime(2000, 1, 1);
DateTime dt2 = new DateTime(2001, 1, 1, 0, 0, 0);
DateTime[] dates = new DateTime[]{dt1, dt2);
Example 2:
Change from this construction:
Label1.Text = Environment.GetEnvironmentVariable(“TEMP”);To this construction:
String text = Environment.GetEnvironmentVariable(“TEMP”);
Label2.Text = text;
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 Studio online help or Appendix C in the Understanding DevPartner manual.
On systems with both DevPartner Fault Simulator 1.5 and DevPartner Studio 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:
There is a known issue that prevents Performance Expert from collecting lock
data for methods that use the MethodImplOptions.Synchronized
attribute.
The Japanese character set is not supported for Naming Analysis in Code Review.
Code Review has alleviated an "Out of Memory" issue for large applications. A side effect of this resolution is a flickering screen while a Code Review session is in progress. This is a known Microsoft issue, and is addressed in Microsoft Knowledge Base article number 555195.
If you notice certain anomalous occurrences, you should install Service Pack 1 for Visual Studio 2003 or Visual Studio 2005. Indications can be the following:
If a C# method contains conditional code of the form #if condition ... #else
... #endif code review processed the code as though it only consisted of the #if
condition branch. Code following the #else branch is ignored.
In some instances, DevPartner Studio intermittently displays the wrong source code line in the Description pane (on the Problems pane) following a code review. This problem is related to underlying Microsoft code. While it is intermittent and random, it does not impact the accuracy of code review results or the ability for DevPartner Studio to successfully perform a Go to Source operation for the rule in question. As a workaround, use the Go to Source function to access the correct location of the source code related to the rule firing.
Code review will only print reports to the default printer. When the Print button or menu option is selected in the code review problems pane, a dialog box appears. This dialog box controls the settings for printing, and allows you to select a specific printer other than the one currently set as default. However, the report will only print to the default printer, regardless of which printer is selected. The work-around is to change the default printer before attempting to print reports from code review.
Code review does not support the LINQ Preview project types in Visual Studio 2005. Some of the new syntax in the C# 3.0 language preview, introduced by these project types, will cause code review to hang.
If DevPartner Studio and Rational XDE Plus are both installed on the same machine, it is possible that incomplete results might be generated during a code review. In this case, No Problems will appear on the Problems pane following a code review on a solution, rather than a complete list of rule violations that you expect to see. The workaround is to uninstall both DevPartner Studio and Rational XDE Plus. Then, reinstall DevPartner Studio before you reinstall Rational XDE Plus. If you install Rational XDE Plus first, you will continue to see these symptoms in DevPartner Studio.
DevPartner Studio will be unable to perform a code review in batch mode if the solution in question is integrated in a source control system. This is not a DevPartner Studio bug, but a Microsoft constraint. DevPartner Studio has no control over the source control integration behavior in the Visual Studio Integrated Development Environment. Source control error messages will be generated even if the Integrated Development Environment is run in Automation mode, such as how the command line interface runs.
The workaround steps follow:
Solutions containing source code that has compilation errors will occasionally
generate a misleading error message when you run a review from the command line
(CRBatch.exe). In these instances, the .err file contains the error message
"Unexpected error: The message filter indicated
that the application is busy."
Fix the errors in the source code and ensure the solution compiles cleanly to eliminate the problem.
User-defined hyperlinks that reference external files might not respond when clicked even though the target of the link is valid. You might encounter this problem if you attempt to click hyperlinks in either the Rule Set list or the Preview pane of the Edit Rule dialog box in the Rule Manager.
Examples include:
<a href="C:\Program Files\Microsoft Visual Studio .NET\FrameworkSDK\Samples\Setup\html\Start.htm">Microsoft .NET Framework SDK QuickStarts, tutorials, and samples</a>"
<a href="file:///C:\Program Files/Microsoft Visual Studio NET/FrameworkSDK/Samples/Setup/html/Start.htm">Microsoft .NET Framework SDK QuickStarts, tutorials, and samples</a>"
When you use 4NT to run the crupdaterules.exe or crupdateprefs.exe migration utility programs, you will encounter a problem if you enter a pipe character (|) as part of the old database path. For example:
crupdateprefs | <path>
Normally, a message would appear in a non-4NT DOS window indicating that you specified an invalid path to the DevPartner Studio database. However, when you include the | character in the command using 4NT, no error message will appear. 4NT prevents the error message from being written to the console despite the presence of the invalid use of this character. The following is an example of a valid command for the rules migration:
crupdaterules C:\MyOldRulesDb\CRRules.dpmdb
Note: Refer to Migrating DevPartner Code Review Custom Rules and User Preferences in the DevPartner Studio Installation Guide for more information.
If you are running an English version of the DevPartner Studio code review feature under a Japanese operating system, some controls in the code review feature and in Rule Manager will not display Japanese text properly. For example, in DevPartner Studio code review, the Solution Tree nodes appear with indecipherable characters. In Rule Manager, indecipherable characters appear in the user interface, i.e., in the New Rule or Edit Rule dialog boxes.
The workaround in the DevPartner Studio code review feature is to focus on the contents of the Problems pane, which are not distorted. The columns labeled File, Project, Method, and Class appear with valid Japanese text. You can customize the results view by rearranging the left-right orientation of those columns for more visibility in the pane. Refer to the DevPartner Studio code review online help (Customizing the Results View) for more information. With Rule Manager, for consistency sake, it is recommended that you enter or edit rule data in English only.
Any Visual Basic .NET code that contains a Declare statement with an Alias clause will be bypassed in a code review when the DevPartner Studio API rules are used to scrutinize the code. This limitation is due to an accuracy issue regarding declared APIs that are also aliased. This limitation only pertains to Visual Basic .NET Declare statements with an Alias clause. Any DLLImport attributes placed on Visual Basic .NET or Visual C# API methods declared as external will still be reviewed successfully.
Window applications that fire design-time property rules might generate an Object reference not set to an instance of an object message in the Visual Studio designer. This anomaly occurs when you attempt to go to source by double-clicking a design-time property rule in the Problems pane in Code Review.
As a workaround, close and reopen the solution. Once the solution is reopened, all successive Go to Source attempts will work correctly.
When using DevPartner Studio 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 Studio will not be able create and submit bugs to the Team Project.
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 Studio 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 Studio 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 automatic snapshot creation.
If you compare a snapshot taken with a previous version of the System Comparison utility with a snapshot taken with DevPartner Studio 8.1.1 or later version, 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 Studio Professional Edition Known Issues
Copyright © 2007, Compuware Corporation
08/09/2007 03:33 PM