More Effective Line Timing with C++ Performance Validator

By , December 20, 2016 5:06 pm

C++ Performance Validator has always had the ability to provide timing information for each line executed. However it has always been a bit clumsy to use – you could only enable line timing for all the methods that were being timed. This could result in slow execution due to methods you didn’t want line timed being line timed. You could filter them by file using the “Hooked Source Files” filter or the “Hooked File Types” filter, but that was about as granular as it got.

We’ve just introduced the capability to specify which classes, class methods and functions get line timed. So now, if you want to time just one function, or one method in a class, or time just the methods in a class, you can tell C++ Performance Validator to do that.

To introduce this capability we’ve had to add an additional filters setting in the Settings dialog, we’ve updated the line timing warning dialog to allow you to edit line timing filters right from the warning dialog and we’ve had to update the context menus on all the displays to include new options for line timing filters. We’ve also had to update the display of filtering information on the line timing display.

Updated Settings Dialog

We’ve added a new “Line Timing Filters” section to the settings dialog.


The image above shows three filters have been selected and that only the classes, methods and functions identified by the filters will be line timed. All other class, methods and functions will be ignored for line timing. All methods in the class seoPage will be filtered for line timing, as well as the method CSpellCheckTabDlg::addWord and the function strncasecmp.

Updated Line Timing Warnings

The Line Timing Warning dialog has been updated to allow you to edit line timing filters directly from the warning dialog. The Edit Line Timing Filters… button displays the Line Timing Filters dialog previously described.

C++ Performance Validator Line Timing Warning Dialog

Updated Context Menus

We’ve added a new submenu to the context menus on all displays and renamed the existing “Instrumentation” submenu to “Function Filter (instrumentation)”. The new submenu added is “Line Timing Filter (instrumentation)”. These new context menu entries allow you to easily specify that a class, a class method or a function should be selected for line timing.


How we expect these filters to be used

There are two main methods for using the line timing filters that come to mind.

  • Specify the filters ahead of time.
  • Specify the filters in response to function timing data you are looking at.

Specify the filters ahead of time

This method relies on you knowing your software code and having a very good idea which methods you think need line timing. Open the settings dialog, go to “Line Timing Filters” and enter your filters as appropriate. Be sure to set the filters to include or exclude methods for the use case you think is useful. For line timing, most of the time we expect you to be using the include setting and specifying just a few methods to line time.


Specify filters based on data.

The alternative way of using line timing is in response to some profiling data that you already have. Ideally you’ll have recorded this profiling data with line timing turned off (you can turn this on/off from the launch application dialog). Once you have the profiling data, search for functions that you think will benefit from additional tuning. When you have a candidate function, right click to get the context menu, then select if you want to profile the whole class, just that class method or just that function for line timing.


At the point you add line timing filters, if you have no line timing filters or the line timing filters are set to profile all classes, methods and functions, then the line timing filters will be set to profile just the classes, methods and functions identified by the filters. However, if there are pre-existing filters, the include/exclude setting of the line timing filter will not be changed – you will need to visit the Line Timing Filters settings dialog to change that setting if you want to switch from include to exclude or exclude to include. This design is deliberate as the main use case is to profile one or two methods (or all the methods in one class) – that use case is “include”, which is why this is the default behaviour.

If you have already recorded a session with line timing data and you specify some line timing filters, C++ Performance Validator will update the line timing display to grey out the classes, class methods and functions that will not be instrumented on the next run.


Line Timing Results

Once you have the filter(s) you need setup you can run a new profiling session to get the line timing data you need.


The Software Updates Menu

By , December 20, 2016 12:35 pm

We introduced the Software Updates menu in 2012. This coincided with the introduction of automatic software updates. Various bug fixes have been applied to the software update software since then. But we’ve done nothing with the software updates menu at all. Until recently.

In response to some unusual problems a few of our customers have had we thought we could improve the experience of using the software updates function.

Problems with authentication

One customer reported that although he’d entered his login credentials, the login and download were failing. But strangely our software wasn’t prompting him for a correct set of login credentials (which is what should happen). After some investigation we found that some failures on our server were being amalgamated into one global error code sent back to the client. The global error code was then interpreted correctly according to the error code, but that response wasn’t correct with respect to the specific error on the server. We broke all the failure points on the server into discrete error codes and now handle all of these individually. This allowed the problem the customer had to come to the surface – their credentials were in fact incorrect – he’d made a typo while entering his details.

In addition to this we’ve now made changes to the email entry fields that validate only correct characters can be entered in an email address – enter any incorrect ones and the field turns red. Not enough @ characters – red, too many @ characters – red, whitespace in the user name which isn’t quoted – red, whitespace in the domain – red. Etc.


There is also the error use case where a customer enters their login details for, say, C++ Performance Validator but the tool they are using when they enter these details is C++ Memory Validator. The login details are valid, but not for this software tool. The image below shows the error message when using the Test Login Details… button.


We also added two new menu entries for resetting the user credentials and also for setting the user credentials. If the user credentials are reset, no software updates will occur. If the user credentials are set (correctly) software updates will occur.


Problems with TMP security

When a software update for one of our tools downloads it’s downloaded by default to the directory defined by the TMP environment variable. On a Windows 10 machine this most likely points somewhere like c:\users\stephen\AppData\Local\Temp.

The TMP environment variable is used by the _ttempnam() function to provide a temporary filename for use by the software that calls it. _ttempnam() uses the TMP environment variable to do it’s job. We wrote the software updater code, tested it, and didn’t really think much more about it until we recently received an email from a customer. I’m going to quote a bit of it below.

I am an IT manager for a software house that uses your Performance
Validator and Memory Validator. With the new threats from ransomware
we have locked down developers machines so files cannot be executed
under the users Appdata folders which contains the users temp folder.

He wanted to know what our filename policy was so that he could whitelist our software updater to run inside the directory that he’d locked down. _ttempnam() returns names that are different each time. There is a pattern to the names we use. I explained the rules but then suggested that providing a dedicated download directory removes the need for whitelisting and provides a better security environment. He agreed. So that’s what I’m going to discuss next.

Specifying a directory

The first thing we had to do is replace the use of _ttempnam() with a user specified directory.

The user specified directory defaults to the same location that _ttempnam() would have used. Consult the _ttempnam() documentation and follow the rules for generating the default value. This is basically using GetEnvironmentVariable() to query the TMP environment variable.

Provide a means for the user to specify the download directory.


The directory needs to exist. If the directory doesn’t exist, it should be obvious as the directory name is entered.


The directory needs to have execute privileges and write privileges. If either of these privileges does not exist for the specified directory the user should be alerted to the fact.



The Reset button allows the directory to be set to the default value.

Add an entry to the Software Updates menu to enable the user to access this dialog. Update the Startup Wizard to allow the software update directory to be specified.


We’ve also updated the software update code to handle the use cases where a valid software update directory is supplied but is then deleted, or it’s permissions altered to deny write or deny execute privileges. This also accommodates the case where nothing changes with the directory but the settings get damaged or corrupted somehow (editing the registry, a machine crash…).


We’re always trying to improve your experience with our software. Whether it’s making the use of Software Updates so easy you don’t need to talk to us about it, or improving your security environment. If you have an issue that you think will improve the software for everyone please do get in touch.

The Startup Wizard

By , December 20, 2016 11:33 am

We’ve just added a new Startup Wizard to all our C++ tools.

The purpose of the startup wizard is to unify the various different dialogs that would be shown the first time the software ran. These would configure different aspects of the software. Placing them all in one place, a wizard, provides a better first run experience. We’ve also taken this opportunity to configure software updates for non-evaluation users of the software. As a final touch, we’ve included an overview video for the software.


The first panel explains what’s going to happen next.


Symbol Environment Variables

The second panel allows you to configure which environment variables (if any) you wish to use to control the symbol search process for symbols contained in PDB files.


IDE / Compiler

The third panel allows you to configure which IDE / Compiler / Linker you are using. This is important as it affects how symbol lookup is performed (Visual Studio has various quirks in its history of symbol handling, we have to work around that).


Software Updates

The next panel is not shown to people evaluating the software. Only purchasing customers see this panel. The panel allows you to configure your software update information and also where the software updates are downloaded to.

It is important to be able to specify where they are downloaded to because of potential security risks that arise from allowing the TMP directory (c:\users\[username]\AppData\Local\Temp) to be executable. We use the TMP directory as a default, but if you think that’s not a good idea you can specify your own download directory and set permissions for TMP to deny execute privileges.


Video Overview

The final panel is a video overview of the software. The purpose of this video is to quickly show many areas of the software to encourage you to explore the capabilities of the software.


Working with Dev C++

By , December 14, 2016 5:57 pm

We’ve had a few people asking how to configure C++ Memory Validator to work with programs built using Dev C++. Dev C++ is an IDE used for developing programs with the MingW compiler.

We tested using this download of Dev C++.

Debug information

Any program built using the default Dev C++ settings will generate a binary image that contains debugging information that is in a format that our tools cannot read. The MingW compiler can create debug information in many formats, including COFF and STABS, both of which our tools support. You can turn these debugging formats on using the -gCoff and -gstabs flags. We recommend using STABS symbols.

Configuring Dev C++

Open the Project Options… dialog from the Project menu.

Choose the Parameters tab. Add the option -gstabs to all three columns. Click OK.

Now that you have configured the debug options all you need to do is to rebuild your project to ensure the debug information is present.

Panorama Theme by Themocracy