The Command Line Builder

By , April 4, 2022 1:32 pm

Last week we introduced the command line builder to all our Validator tools – Bug Validator, Coverage Validator, Memory Validator, Performance Validator and Thread Validator.

All our tools provide command line support allowing you to use them from your favourite automation tool, be that a set of batch files, or something more comprehensive like Jenkins.

Command lines are great, but writing out your command line can be daunting, even if like me, you’ve done it many times. It’s not that it’s hard, it’s just that you don’t do it very often so the options are never top of mind, you’re going to have to go and look at the dreaded documentation.

Yup, documentation, even when it’s as good as ours is, you’re still reluctant to look at it. I know the feeling. You’ve got so used to using a nice GUI that it seems odd to look at the help. But you’ve got to do that if you’re going to write a command line for a tool.

That’s where the Command Line Builder comes in. To reduce the amount of time spent looking at the documentation, and to reduce the likelihood of you making mistakes when creating your command line.

How do I start the command line builder?

The command line builder can be started from the Launch menu and from any of the Launch dialogs and Launch wizards.

Launch Menu

Launch menu

When the command line builder is started from the launch menu you are presented with a set of choices that allow you to preconfigure the command line builder.

Command line builder wizard

The choices provided aim to cover every possible way of using the Validator.

  • Build my own command line.
  • Use a predefined template that provides the command line arguments for common command line tasks. These templates are configured specific to the validator being used. If the Validator supports .Net and .Net Core as well as native there will be .Net specific templates and .Net Core specific templates. If the Validator can also do specific things like merging sessions or comparing sessions, templates for these actions are also provided.
  • Use an existing command line I use to launch my program. You know what you’d type on a command prompt to launch your program. Type that here and let the command line builder turn that into a command line for the Validator.
  • Use an existing Validator command line. Reuse a command line you already have and tweak it a bit to do the new task.
  • Use an existing Validator command file. Reuse a command file you already have and tweak it a bit to do the new task.

With the exception of the first option that allows you to build your command line from scratch, all of these options are present to enable you to save time when building your command line.

Once you’ve chosen your option (and template if you’re using a predefined template) you need to move to then next stage, with the thoughtfully named Next button.

Launch dialog / wizard

When you start the command line builder from a launch dialog or wizard it’s via the Cmd Line… button.

Launch dialog showing Cmd Line... button

When you start the command line builder this way, a command line is built based on the options you have selected on the launch dialog/wizard, and then passed to the command line builder. This allows you to select a known good command line you’ve previously used then click the Cmd Line… button and instantly be able to configure that command line in the command line builder.

Command Line Builder dialog

Once you’ve started the command line builder you’ll be presented with a dialog that will look very similar to this. This example is using a preconfigured template for Coverage Validator that merges coverage data to a central session, exports HTML and XML coverage data, and saves the coverage session.

The first thing you’ll notice is there are many argument values highlighted in red. These are values that are incorrect. This is because they are from a template and you’ll need to edit them to match your own working practices – in this example you’ll need to edit the program being tested and change c:\myResults to be where you wish to save your test results and edit the filenames to something meaningful for your tests.

Each command line argument is displayed on it’s own line, with a value (for the arguments that have a value) and a description of what this argument/value pair represent. If you need help, the ? button in the dialog border will take you there.


The buttons on the right hand side provide simple editing of the list of argument values to allow you to Add an argument, Edit an argument or value, Remove an argument and Remove All arguments. You can also start editing any existing argument or value by double clicking it.

Editing an argument presents you with a combo box of valid Validator argument values, preventing you from entering incorrect command line arguments.

Editing a value that is an On/Off, Yes/No, True/False type of argument presents you with those choices.

Editing a value that is an enumeration will only show you valid enumeration values.

Editing a value that needs a directory will open a directory chooser dialog, editing a value that needs a file will open a file chooser dialog set to choose that type of file.

All other editing types use a standard text dialog, with limited text input (for example integer values only allow integer input).

As you can see we are trying to reduce the scope for input error as much as we can.

Additional Customization

Next to the editing controls are some customization controls which allow you to add command line arguments (and associated values) to your command line if they are not already present.

Add Hide adds the -hideUI argument which you will need if you are writing command lines for automated use that close the Validator after the target program finishes.

Add Debug adds options to help debugging failures with the command line. These options ensure the command prompt is displayed, that the arguments you think you are supplying are the arguments you’ve supplied, displays error information on the command prompt and displays error information in a message box.

Add Export adds options for exporting in HTML and XML. For Coverage Validator an additional XML Cobertura export option is available.

A fourth button is displayed for some Validators. This provides options specific for that Validator, for example merging coverage data, or comparing memory leak reports or comparing performance reports. In the image show above you can see Add Merge, which is for Coverage Validator.

The last button allows you to Import an existing command file. Using this destroys all existing arguments and replaces them with the values in the command file.

Creating the command line

Once you’ve finished creating your command line the next thing is to get the command line in a form that you can use. We provide two forms of command line creation. The normal command line that most people expect and a much shorter command line combined with a command file that contains the actual command line instructions for the Validator.

The choice of command line is made using the combo box towards the lower half of the dialog.

Command line with arguments

This option is the typical command line that people expect. It starts the Validator and passes all command line arguments and values to the Validator.

The command line is updated each time the arguments and values are edited.

The Copy button copies the command line to the clipboard.

Command line with command file

This option provides a short command line that loads the command file, with the command file containing all the command line instructions for the Validator. There are two reasons for using the command file:

  • A shorter command line. Current versions of Windows support very long command lines. Earlier versions of Windows supported much shorter command lines – it was quite easy to construct a Validator command line that was too long for Windows to process, resulting in incorrect behaviour when you tried to use the command line. Using the command file allows you to specify long command lines on older operating systems.
  • Simplifying command line management. Storing all your command lines in command files allows you to easily manage the command files, storing them all in one place. It also allows some indirection, allowing you to edit the command line without editing the script/tool that invokes the Validator.

When you choose to use a command line with a command file, if you have not specified a command file to use you will be prompted for a command file name. When a command file name is specified the command file will be updated each time the arguments and values are edited.

The Browse… button allows you to use a file browser to choose a command file name. The View… button allows you to view the command file in your favourite editor.


Once you have created the command line arguments and values, and chosen the type of command line you want to use, you may want to test the command line. This is done by using the thoughtfully named Test Command Line button.

If all goes well a new Validator instance will be launched with your command line, and some time later the target program will complete.

Unfortunately not all command lines are equal, and some will fail to run correctly. So how do you debug that?

Incorrect program

If you have misconfigured the command line (for example: by specifying a 64 bit program to be tested by a 32 bit Validator) you will not get the behaviour you expect.

If you have specified the startup program correctly but failed to ensure that all dependent DLLs can be found the program won’t start, or it will start and then fail shortly afterwards. Check you can start the program in this directory by double clicking it – if that doesn’t work you’ve probably got a missing dependency. You can check your dependencies using PE File Browser.

If you have specified a startup directory that does not exist, the program won’t start.

Unable to see error dialogs and warning dialogs

If you have specified -hideUI you won’t be able to see what happens, so if you are having problems, the first thing to try is to change -hideUI to -showUI and test again to see if any warning dialogs are displayed.

Show the command prompt

Use -showCommandPrompt to ensure the command prompt can be seen. You may find a helpful error message waiting for you.

Check the arguments supplied

Use -echoArgsToUser to check the arguments supplied are what you think they should be.

Ensure you can see errors

Use -showErrorsWithMessageBox to display any error messages with a message box. Use this when your program has a graphical user interface.

Use -showErrorsOnCommandPrompt to display any error messages on the command prompt. Use this when your program is a console program and doesn’t have a GUI.


The Command Line Builder simplifies the creation of valid command lines for use with the Validator tools. We’ve tried to eliminate errors by making it easier to create valid command lines while also highlighting errors with proposed command line values.

Using and Debugging Environment Variables

By , February 28, 2022 6:31 pm

Environment variables can be used to configure the various Validator tools that we provide. Configuration provides flexibility, but it also provides avenues for failure. In this article I’m going to show you how you can configure our tools using environment variables, and how you can debug them if that configuration goes wrong.

In this article I’m going to use Coverage Validator, but these topics also apply to Bug Validator, Memory Validator, Performance Validator and Thread Validator.

Should I use % or $?

Note that you can use % to delimit env vars, as in %PATH%, or you can use $ to delimit env vars, as $PATH$. If you use % the command shell (or batch file processor) will do the substitution before the Validator gets to see the command line. If you use $ the command shell will not do the substitution for you, the Validator will do the substitution.

Using environment variables

Any Validator command line option that also takes an argument can have that argument supplied by an environment variable. For example:

  • -program e:\test\test.exe
  • -directory e:\testArea
  • -arg 1
  • -arg “strawberry ice cream”

Using environment variables the above could become

  • -program $TEST_PROGRAM$
  • -directory $TEST_AREA$
  • -arg $TEST_COUNT$

A slightly more complicated command line could look like this:

coverageValidator.exe -program $BUILD_DIR$\test.exe -directory $TEST_DIR$ -fileLocations $TEST_DIR$\fileLocations.cvxfl

This command line starts test.exe located in directory identified in the BUILD_DIR environment variable, with the current directory set to the directory identified in the TEST_DIR environment variable, and sets the source code file locations to the list of files specified in the fileLocations.cvxfl file in the directory identified in the TEST_DIR environment variable.

The fileLocations.cvxfl file can also contain environment variable definitions:


The environment variables in the fileLocations file (or any other file where environment variables are used) are substituted for the environment variable definitions when that file is loaded. In the example above, if the SRC_DIR environment variable had the value “e:\abcMusicTutor” the file contents lines would evaluate to:


As you can see the use of environment variables allows you to setup a general framework for controlling Coverage Validator from the command line, but then customise that usage by setting the environment variables appropriately.

What happens when things go wrong?

When using environment variables there are a few things that can go wrong:

  • The environment variable isn’t defined
  • The value in the environment variable is wrong
  • The value in the environment variable doesn’t exist

You can view the environment variables in the Validator, the target application, and any environment variable substitution errors using the Env Vars tab in the Diagnostic part of the Validator.

To view the environment variable substitution errors choose “Environment variable errors” in the combo box on the Env Vars tab.

Environment variable not defined

All the Validator tools check if an environment is defined or not. Environment variables that are not defined are logged and reported on the Diagnostic Environment Variables display. In addition, any locations where the substituted value is meant to be used as a directory or filename (the fileLocations example) will show the non-substituted path ($SRC_DIR$\model) and will be highlighted in an error colour indicating an invalid path.

Example: These are values loaded via -fileLocations. The environment variable SRC_DIR does not exist. The file locations dialog lists the invalid paths in red.

Example: These are values loaded via -fileLocations. The environment variable SRC_DIR does not exist. The columns show the environment variable name, the original string value being parsed, a comment indicating where this option was encountered and a timestamp.

Environment variable is wrong

Each Validator can’t tell if a value is wrong. This is a subjective matter. For example: -numSession $NUM_SESSION$.

If NUM_SESSIONS is set to 1 when you’d prefer it to be 2, that’s an error will stop you loading multiple sessions and comparing them, but it’s not an error that will prevent Coverage Validator from performing code coverage.

As such debugging this error is something that requirement your judgement. Examining the Diagnostic Environment Variables displays will help you identify what the problem is.

Value in the environment variable doesn’t exist

A common error case is where the environment variable specifies a directory but the directory does not exist. A related error case is when a filename is specified but does not exist. For cases like fileLocations where the values loaded can be inspected in the settings displays you will see the specified folder location listed in an error colour indicating an invalid path.

The best way to debug this class of error is to open the settings dialog (Settings->Edit Settings…) and examine all settings looking for paths in the error code (the default for this is red).

Example: Here environment variable SRC_DIR did exist and was substituted for e:\abcMusicTutor, but that directory does not exist.

How do I view the Validator’s environment variables?

To view the Validator’s environment variables, on the Diagnostic Env Vars tab, choose “??? Validator” in the combo box, in this example “Coverage Validator”. The environment variables will be shown below.

How do I view the target application’s environment variables?

To view the target application’s variables, on the Diagnostic Env Vars tab, choose “Application being monitored” in the combo box. The environment variables will be shown below.

If you launched the target application from the Validator the target application’s environment variables will be similar to those in the Validator, but with some additional env vars to control .Net profilers and and some other SVL_ prefixed env vars to communicate various data to Software Verify components that are loaded.

If you launched the target application as a standalone application, or service and used one of our APIs to connect to the Validator, the environment variables shown will reflect those in force at the time the application/service was started, and the account that application/service is running on.

Protected: Figma design to WordPress

comments Enter your password to view comments.
By , February 14, 2022 3:44 pm

This content is password protected. To view it please enter your password below:

Exceptions Codes you’ve never heard of

By , January 28, 2022 3:33 pm

If you write software for any length of time you’ll have seen your software fail in a variety of ways.

Exceptions are a common cause of application failure.

Exceptions are also used to handle unusual error cases, with the intention that the calling code is aware of this exception and will handle it, ensuring that the application doesn’t fail.

For this article I’m going to be discussing Win32 structured exception handling (SEH) exception codes. I’m also going to assume that you’re using Visual Studio, a Windows SDK or another IDE, such as C++ Builder, or Delphi.

Most of the exception codes you’ve likely encountered in your career can be found declared in ntstatus.h

Depending on which version of Visual Studio you’re using some exception codes may not present.

I’m going to list exception codes that we’ve found during the process of developing software tools at Software Verify.

Many of these exception codes are not documented, or are only present in recent versions of SDKs, which you may not be using because you’re still using an older Visual Studio.

Where possible we’ll indicate additional sources of information about a given exception code. We’ll indicate the actual exception code and what name we use to reference it. We’ll also include a downloadable header file so that you can use these definitions without needing to type them in yourself.

Visual Studio Specific

These exceptions are specific to Microsoft Visual Studio and Microsoft compilers and linkers.

Microsoft Thread Naming Exception


This exception is used to communicate to a debugger (or any other monitoring tool) a suggested name to represent the thread. This is technique is discussed in this blog post. It has been replaced in Windows 10 by SetThreadDescription().

Visual Studio C++ Exception


This exception is used to implement C++’s exception handling.

This is discussed in this blog post.

.Net specific

These exceptions are specific to the Common Language Runtime (CLR), used to implement .Net. Most of these exception codes we found while inspecting .Net Core open source code. A few of them we have found elsewhere.

CLR Fatal JIT Exception


This definition comes from .Net Core open source code.

CLR Data Checksum Exception


This definition comes from .Net Core open source code.

CLR First Chance Exception


CLR Bootup COM+ Exception


This definition comes from .Net Core open source code.

CLR Exception


CLR COM+ Exception


This definition comes from .Net Core open source code.

Many causes of this exception are discussed here.

CLR HIJACK Exception


This definition comes from .Net Core open source code.

CLR Notify Exception


This definition comes from .Net Core open source code.

CLR EXX Exception


This definition comes from .Net Core open source code.

CLR SEH Verification Exception


This definition comes from .Net Core open source code.

CLR Internal ASSERT Exception


This definition comes from .Net Core open source code.

Embarcadero specific

The exceptions are thrown by software made with tools from Embarcadero (formerly Borland).

Delphi Exception 1


This is an exception thrown by Delphi.

Delphi Exception 2


This is an exception thrown by Delphi.

C++ Builder Exception


This is an exception thrown by C++ Builder.

Windows SDK

These exceptions are Windows exceptions that may or may not be defined in the IDE/SDK that you are using.

For more information you can look up error codes and exceptions here and here.

Fatal Memory Exhaustion


The process cannot allocate any more memory.

Fail Fast Exception


This is used by the Kernel to handle fail fast exceptions. See the list of fail fast codes.

Stack Buffer Overrun


This used to be used to indicate that the user mode callstack had had a buffer overrun, corrupting the stack and potentially opening up the application to the a malicious attack.

This exception code has been repurposed. It is now used to handle user mode fail fast exceptions. The first parameter passed with the exception is the fast fail code.

Invalid C Runtime Parameter


This is used to indicate that invalid parameters have been passed to a C runtime function. An example of this would be passing too small a string buffer to a _stprintf_s();

Heap Corruption


A Win32 heap (HeapCreate, HeapDestroy, HeapAlloc, HeapReAlloc, HeapFree) has had it’s internal structures corrupted.

Invalid Exception Handler


An exception handler was expected but not found.

You can often see this in 32 bit programs where the stack (containing the stack based exception handler) has been corrupted.



Bad Stack


During an unwind operation an invalid stack location, or a misaligned stack location was found.

Invalid Unwind Target


During an unwind operation and invalid unwind target was found.

Fatal User Callback Exception


An unhandled exception was found while handling a user callback.

Invalid Image Format


The specified file is not a PE format file, or it is a PE format file for a different processor architecture than the version that Windows is running.

To inspect PE files you can use PE File Browser.

Debugger Inactive


Windows may have been started without Kernel debugging enabled.

Certificate Expired


The certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file.

x86 Breakpoint


Exception code used by the Win32 x86 emulation subsystem.

Debug Reply Later

0x40010001 DBG_REPLY_LATER

Debugger will reply later.

Debug Unable to provide handle


Debugger cannot provide the handle requested.

Debug Terminate Thread


Thread terminated by debugger.

Debug Terminate Process


Process terminated by debugger.

Debug Control-C

0x40010005 DBG_CONTROL_C

Debugger received Ctrl-C.

Debug Print Exception Char


Debugger received message from OutputDebugStringA();

Debug RIP Exception


Debugger received RIP exception.

Debug Control Break


Debugger received Ctrl-Break.

Debug Command Exception


Debugger communicating a command.

Debug Print Exception Wide Char


Debugger received message from OutputDebugStringW();

Debug Exception Not Handled


Debugger did not handle the exception.

Assertion Failure


An assertion failed. See NT_ASSERT() and NT_ASSERTMSG().

Fatal Application Exit


Application exited via a call to abort(); or as a result of a fast fail exception.

Application Hang


Application Verifier Stop


Application verifier has found an error in the current process

Procedure Not Found


This is a Software Verify name for this exception, we can’t find an official name.

Header File

I hope you found the above list useful.

You can download the exceptionCodes.h header file.

Fail Fast Codes

By , January 11, 2022 3:09 pm

When Windows encounters an error condition that might compromise the security of the computer, the program that encounters that condition is terminated as fast as possible. This is done via the Fast Fail mechanism.

Fast Fail is implemented as an intrinsic, which means you can’t redefine it, and you can’t hook it from user mode code. On x86/x64 it’s implemented as an interrupt call, which is handled inside the kernel.

The definitions for these codes are in winnt.h.

FAST_FAIL_LEGACY_GS_VIOLATION0Do not use. Legacy value.
FAST_FAIL_GUARD_JUMPTABLE37Compiler uses this value. Do not change.
FAST_FAIL_CAST_GUARD65Compiler uses this value. Do not change.

The FAST_FAIL_LEGACY_GS_VIOLATION definition is a legacy value and is reserved for compatibility with previous implementations of STATUS_STACK_BUFFER_OVERRUN exception status code.


Fail Fail is invoked using the __fastfail() instrinsic.

__fastfail() takes one argument, the fast fail code, and is defined as shown below. Calls to __fastfail() do not return.

#if _MSC_VER >= 1610

    _In_ unsigned int Code

#pragma intrinsic(__fastfail)



In user mode code __fastfail() will be seen as a non-continuable second chance exception with code 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN). There is no first chance exception to be handled. This is deliberate – it is assumed that the program state is corrupt and that the exception handling mechanism may have been compromised (think virus, etc).

The fast fail code is the first parameter supplied with the second chance exception. There may be other parameters.

In kernel mode __fastfail() is handled by a specific bugcheck code 0x139 (KERNEL_SECURITY_CHECK_FAILURE).

If a debugger is present it is given a chance to inspect the program before it terminates execution.


Native support for __fastfail() was first implemented in Windows 8.

Earlier operating systems will still terminate the application in response to a __fastfail(), via the exception handling or bugcheck mechanism as appropriate to the user/kernel mode.

The header file definition indicates that Visual Studio 2012 (_MSC_VER 1700) onwards include support for __fastfail().

Both Visual Studio 2010, and Visual Studio 2010 SP1 have _MSC_VER defined as 1600. I can’t find an entry for 1610 anywhere.

log4j status

By , December 14, 2021 10:33 am

We’ve had a few inquiries from worried customers as to whether we use log4j and what our mitigation plan is if we do.

Good news: We don’t use log4j. Our website doesn’t use Java.

There is nothing for us to do, and nothing for you to be concerned about.

Viewing source code that’s in the “wrong place”.

By , November 26, 2021 7:15 pm

You’ve been given a program to debug. You’ve got the EXE and DLLs, and you’ve got the PDB files, so you can tell when the filenames, line numbers and symbol names are.

So far so good.

You’ve also got access to the source code, but the source is not on your machine, it’s on the original machine that the EXE and DLLs were built on.

How do you view the source using the various Validator tools? The answer is the same for all the Validators, so I’ll just concentrate on showing you how to do this with Coverage Validator.

Build Machine: XPS13

First we need to create an application on the build machine and trying working with it on the test machine.

I’m going to create exampleApp on the machine xps13 on drive D:\ in the dev directory. It’s an MFC application built with the standard MFC app project creation wizard.

Drive D on xps13 is shared. Full path to the application: \\xps13\d\dev\exampleApp\exampleApp

Test Machine

On the test machine I’m going to create a similar directory structure to the test application, but it will only contain executable and PDB files. There will be no source code.

Coverage Validator : First Run

If we just run Coverage Validator without telling it where the source code is, the PDB file will be found and code coverage will be performed using the debug information, but it won’t be possible to view the source code because the source code paths point to d:\dev\exampleApp\exampleApp on the test machine. There is no source code on the test machine.

If you click on the filename on the left hand panel a Find source file dialog box is displayed because the source file can’t be found at the specified location, or in any location in the Coverage Validator settings.

Configuring Source Code Location

For the dialog box above there are three options, two of which are useful in this scenario:

  • Search Folder…. Use the Microsoft Folder dialog to navigate to the location of the source code on the build machine. For this example you need to choose the folder d:\dev\exampleApp\exampleAppon the networked machine xps13

  • File Locations…. Edit the Coverage Validator file location definitions. This will display a version of the File Locations tab which can be found on the Coverage Validator settings dialog.

The file location definitions can also be edited from the Coverage Validator settings dialog, which you can access via the Settings menu.

The first thing to note is that default display for File Locations is the location of PDB files. We need to add the path \\xps13\d\dev\exampleApp\exampleApp to the Source Files section.

  • Change the Path Type combo to Source Files.

  • Click Add… to add a path to the list of paths.

  • Type the path \\xps13\d\dev\exampleApp\exampleApp into the edit box.

  • Click OK to accept the new settings.

Viewing Source Code

Now that we have the source code location correctly configured if we click on the filename in the left hand panel we will see source code in the right hand panel.

It’s possible that for your application you have more than one path to your source code on the build machine. If that’s the case just add as many paths as you need to the Source Files section of the File Locations settings.


You’ve learned how to configure alternate locations to look for source code, useful for when the source code is in a different location than when the application was built.

Code coverage with NUnit and Coverage Validator

By , October 29, 2021 12:52 pm

In this blog post I’m going to give you an example for running .Net unit tests with NUnit and Coverage Validator. It’s the same process for .Net Core and C++.

I’m going to show how to do with with NUnit 2.7.1, but this method will work with any version of NUnit, 2.x or 3.x.


We’re going to be testing with the console version of NUnit, nunit-console.exe. The program that runs the tests is nunit-console.exe, not a child process, so unlike working with VS Test, we don’t have to configure the application to monitor.

Video or step-by-step

I’ve created a video showing you how to configure Coverage Validator, but if you prefer step-by-step instructions, these are listed below the video in this blog post.

Coverage Validator

To get started we need to launch nunit-console.exe to run the tests.

Click the Rocket icon on the toolbar. This will display the Launch Application or Service dialog.

Choose Launch Native and .Net applications.

nunit-console.exe is a .Net application, so we’ll use the regular .Net and native launcher.

You can also launch using Launch->Applications->Launch Application…, or F4, these will take you straight to the launch dialog/wizard, skipping the previous dialog.

The Start a Native/.Net application dialog is displayed.

Now we have to configure the start application dialog. We’ve got to:

  • choose the application to launch

  • set the unit test DLL to test

  • set the startup directory

  1. Set the application to launch.

    Next to the Application to Launch field click Browse… and select your nunit-console.exe

  2. Example: E:\om\c\3RD_SRC\nunit\NUnit 2.7.1\bin\nunit-console.exe

    Note the that after editing the Application to Launch field the Application to Monitor field will auto-populate itself, choosing a default value for the application to monitor. For our purposes the default value should be identical to the application to launch.

  3. Arguments: Enter the full path to your DLL to test.

    In this example I’m going to test the Money.Tests.dll unit test DLL in the C# samples master which you can download from GitHub.

    Example: E:\om\c\3RD_SRC\nunit\nunit-csharp-samples-master\nunit-csharp-samples-master\money\bin\Debug\Money.Tests.dll

  4. Startup Directory. Enter a path for the startup directory. A default will have been set based on the Application to Launch, but for unit test work you’ll need a writeable directory, so you’ll need to edit this value to something appropriate.

  5. If you’re using the Launch Dialog click Launch.

    If you’re using the Launch Wizard click Next until you get to the last page of the wizard then click Start Application.


For the test I’ve configured in this blog post, the results show code coverage for the unit tests.

There is no test framework code to filter out, no autogenerated code to filter out, just the results.

If you want to see how to filter results, take a look at the VS Tests code coverage article.

Any questions?

Hopefully this blog post has answered your questions about how to get code coverage with NUnit and Coverage Validator.

But you may have other questions. Please let us know at and we’ll be pleased to help you.

Code coverage with VS Test and Coverage Validator

By , October 26, 2021 9:33 am

In this blog post I’m going to give you an example for running .Net Core unit tests with VS Test (formerly MS Test) and Coverage Validator. It’s the same process for regular .Net and C++.

First, let’s discuss the program we’re going to launch and the program we’re going to monitor.


VS Tests are run by vstest.console.exe. So that’s the program we’re going to launch. On my machine the path is:

C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe

In this example I’m showing VS 2019 community edition, but it doesn’t matter which VS or version you use.

vstest.console.exe is not a .Net Core application (it’s a regular .Net application). You can check this with our free tool PE File Browser.


vstest.console.exe executes the tests by running testhost.exe. We need to identify which testhost.exe to run (there will be several installed on your machine) and then configure Coverage Validator to monitor that testhost.exe when vstest.console.exe is run.

We haven’t worked out a way of identifying which testhost.exe VS Test is going to use, but once you’ve found it that will be the one forever.

On my machine testhost.exe is in c:\users\stephen\.nuget\packages\microsoft.testplatform.testhost\16.5.0\build\netcoreapp2.1\x64\testhost.exe

Note that despite the path testhost.exe itself is not a .Net Core application (it’s a regular .Net application).

Video or step-by-step

I’ve created a video showing you how to configure Coverage Validator, but if you prefer step-by-step instructions, these are listed below the video in this blog post.

Coverage Validator

To get started we need to launch vstest.console.exe to run the tests.

Click the Rocket icon on the toolbar. This will display the Launch Application or Service dialog.

Choose Launch Native and .Net applications.

Although we’re going to monitor code coverage in a .Net Core DLL, the application we’re going to launch to do this is not a .Net Core application, so we’ll use the regular .Net and native launcher.

You can also launch using Launch->Applications->Launch Application…, or F4, these will take you straight to the launch dialog/wizard, skipping the previous dialog.

The Start a Native/.Net application dialog is displayed.

Now we have to configure the start application dialog. We’ve got to:

  • choose the application to launch

  • edit the applications to monitor

  • set the application to monitor

  • set the arguments for the unit test

  • set the startup directory

  1. Set the application to launch.

    Next to the Application to Launch field click Browse… and select your vstest.console.exe

  2. Example: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe

  3. Edit the applications to monitor. This is a multi-stage process. If the application to monitor has never been configured for the application being launched, you will need to configure the applications that can be set as possible applications that can be monitored. If the application to monitor has been configured, you can edit it to add or remove applications, or you can just use the selection of configured applications.

    Note the that after editing the Application to Launch field the Application to Monitor field will auto-populate itself, choosing a default value for the application to monitor. If this has never been configured before it will choose the same application as the application being launched (in this case vstest.console.exe). If this has been configured it will choose the default application for the configuration.

    For this blog post I’m going to assume that the application has never been configured, and show you how to configure it. Editing is just a subset of these actions and does not need it’s own blog post. If you already have applications to monitor configured you can skip this step.

    Next to Application to Monitor, click Edit…

    • The Applications to Monitor dialog is displayed.

    • We need to add an application to the list of application to monitor.

      On the Applications to Monitor dialog click Add…

      • The Application to Monitor dialog is displayed.

        Note that the EXE and DLL are set to represent the current application you are launching. For Native and .Net applications the DLL field will be empty (only set for .Net Core applications).

        If you wish to edit these value to configure for a different application than the one you are launching you can edit these via the Edit… button.

      • On the Application to Monitor dialog click Add…

        • The Application and DLL dialog is displayed.

        • On the Application and DLL dialog click Browse… and select your testhost.exe

          Example: c:\users\stephen\.nuget\packages\microsoft.testplatform.testhost\16.5.0\build\netcoreapp2.1\x64\testhost.exe

        • click OK to accept the EXE and DLL combination.

      • You should now have two entries, one for testhost.exe and one for the testhost.exe with a full path.

        You can repeat the Add… process for any additional applications you wish to configure.

        Optional: If you want to set this as the default application to monitor choose the appropriate entry in the Default application to monitor combo box.

      • click OK to accept the list of applications to monitor.

      The Applications to Monitor dialog should now show one entry for vstest.console.exe and testhost.exe.

    • click OK to accept these definitions of applications to monitor.

  4. Set the application to monitor.

    In the Application to Monitor combo select the entry for testhost.exe.

    We intend to monitor the first testhost.exe that is launched, so set the Launch count to 1.

  5. Arguments: Enter the full path to your DLL to test.

    Example: E:\om\c\testApps\unitTests\HelloWorldCore\HelloWorldCoreNUnitDotNet5\bin\Debug\net5.0\HelloWorldCoreNUnitDotNet5.dll

  6. Startup Directory. Enter a path for the startup directory. A default will have been set based on the Application to Launch, but for unit test work you’ll need a writeable directory, so you’ll need to edit this value to something appropriate.

  7. If you’re using the Launch Dialog click Launch.

    If you’re using the Launch Wizard click Next until you get to the last page of the wizard then click Start Application.


For the test I’ve configured in this blog post, the results show code coverage for the unit tests, for the code tested by the unit tests, for some autogenerated code, and for some code in the test framework.

Some of the results are from code that isn’t your unit tests. You’ll need to filter these results by configuring Coverage Validator to ignore these code locations in future tests.

Filtering Autogenerated Code

To filter out of the autogenerated code, right click on the entry and choose Instrumentation Filter->Exclude Filename.

Filtered out entries are shown in grey. Next time you run the instrumentation they won’t be included in the coverage results.

Filtering Test Framework Code

To filter out the test framework code, right click on the entry and choose Instrumentation Filter->Exclude DLL.

Filtered out entries are shown in grey. Next time you run the instrumentation they won’t be included in the coverage results.

Any questions?

Hopefully this blog post has answered your questions about how to get code coverage with VS Test and Coverage Validator.

But you may have other questions. Please let us know at and we’ll be pleased to help you.

Living with Repetitive Strain Injury (RSI)

By , June 5, 2021 2:08 pm

This article was written by myself in 2000/2001 and was originally hosted on a different website that no longer exists.

I have updated this with some extra information and fixed many typos.

I no longer suffer the physical health or mental health problems described below. I am re-posting this article in response to a discussion with someone on twitter who is in the early stages of suffering with RSI. I hope that by posting this RSI related article people will read it, understand there is a way out of this problem if they take the correct action.

Your health is the single most important thing you have.

Without health everything else in your life suffers. Health is more important than wealth.


My history with RSI goes back to 1988, culminating in being so ill in 1993/1994 that I had to take 3 months off work, and spend the next 3 months working slowly with the aid of voice recognition. During this time I had to do remedial exercises 3 or 4 times a day, lasting between 20 and 40 minutes each session, and go for a 2 hour walk each day. This exercise regime was intended to improve my posture, range of movement and muscle strength.

Since returning to work, I have been able to reduce the amount of exercises by taking vitamin B6 supplements (Vitamin B6 helps tendon sheath healing) and swimming at least every other day, and preferably every day. I have found that for my level of health, I can swim 750m (30 lengths of average 25m pool) without incurring further injury, but that if I swim beyond length 850m (length 34) I often do more damage to my arms than the benefit I gain. It has taken me 8 years to regain this level of fitness.

Whilst ill I have experienced feelings of helplessness and depression because of this helpless feeling. I have had pains I can’t describe to other people (because RSI doesn’t feel like other pains). I have had to put up with people accusing me of being a malingerer, a work shy person. I have had this accusation even when I worked for myself. Just because I look healthy, doesn’t mean I am. I have at times had very cold hands, and once for a period of 2 weeks I had two blue hands. This was very painful.

I’ve explained this background in brief so that when you read this information you realise that I have very real and painful experience of how debilitating RSI can be. Having established this fact, hopefully you will place some credence on the advice given here. I’m not trying to claim that I’ve had worse RSI than someone else. Its not a competition :-). I have had a bad time, and I have come out the other side and kept my career. Mainly because I pay strict attention to my exercise regime, and when in too much pain I abandon all activities that are not essential, in order that I can recover my health and remain able to work. Against that playing a mandolin or bagpipe doesn’t count for much, however much fun. I stress this because if someone can be as ill as I was and still keep their career, the odds are that the same result can happen for you.


RSI is known as WRULD (Work Related Upper Limb Disorder) in the USA. This name is misleading. RSI can affect all parts of the body, and is not necessarily caused by solely by your work. It is most likely caused by an interaction between your work activities and your non-work activities. For example double-hand use when a software engineer goes home then plays their musical instrument in the evening. Calling the injury WRULD is overly specific and focuses on the wrong things. RSI is a far better descriptor because it describes what is happening without making any claims about which part of they, or which activities are responsible for the problem.

Types of RSI that may affect you as a software engineer

Typical RSI related arm/hand injuries are epicondylitis, bursitis, tenosynovitis, tendonitis and carpal tunnel syndrome.





Carpal tunnel syndrome


Try not to let anyone inject you with cortisone. You can only have this 3 times in your life (it is not good for your bones).

Also this is treating the symptoms, not the cause.

Its a painful injection, I’m told, but does provide short term relief.

Carpal tunnel surgery

Carpal tunnel surgery. I’d advise against it, if you can get proper medical treatment you won’t need it. I’ve heard some nightmare stories about it taking up to 6 months for the operation to heal. However I met a doctor last year, and she had had both her wrists done for this operation and was back at work a few weeks later. I guess there is a lot of variance with this operation.

It won’t happen to me

Do seek advice. Don’t think “I’ll live with it, it won’t happen to me”. Everyone thinks that and they always realise they were wrong, when it is too late.


Your environment should be changed to suit you, not you change to suit the environment. The classic mistake that most people (myself included) make is to get to a workplace, adjust the chair height to suit the desk height and their own height. This is the wrong way around!

The body you have is the one you have to live your life in. You can’t realistically change your height, the length of your torso, the length of your legs and the width of your hips etc. Given that these are not available for modification, we must turn to your work environment.

Lets face it you spend 8 or more hours a day at work. Thats a 3rd of your life you spend there, so you’ll want it to help you and not damage you. If you have a good employer, they will also appreciate that its in their interest to keep you happy and healthy, as happy and healthy employees tend be more efficient, make less mistakes, take less days sick and be more likely to stick around rather than look for a new employer.

So how do we do this? First off we start with how you sit, and what you sit on, not the desk you sit at (we’ll come to that later).


  • You should have a chair with a five (or more) castor base.

  • The chair should be able to rotate

  • The chair seat should be adjustable in height.

  • If possible the chair seat should tilt forwards and backwards.

  • The chair back should be the length of your back and fully support your shoulders.

  • The chair back should be adjustable vertically.

  • The chair should have independently adjustable arms.

How should the chair be adjusted?

  • When sitting the chair, the chair height should be such that with your feet flat on the floor, you can sit in the chair comfortably.

  • The chair seat should be tilted slightly so that the front of the seat is slightly lower than the back of the seat. This causes your pelvis to tilt and improve the ‘S’ shape of your spine to provide more support to your body. This also causes your shoulder and head to be balanced better.

  • The chair seat depth should be chosen (on good chairs you can do this when you buy it) so that when sitting on the chair, you can get your hand (about 3 or 4 inches) between the back of your knee and the seat edge. If the chair is too deep you’ll never be comfortable. If the chair is too shallow you won’t get enough support.

  • Adjust the chair back to support both the lower back and your shoulders. This should not be a problem if the correct length back was purchased with the chair.

  • The angle of the chair back should be quite upright and not laid back. A degree of personal preference comes in here, but basically the more upright it is, the better your posture will be, the more laid back it is, the worse your posture will be and the resulting likelihood of RSI increases.

Good chairs don’t have to cost a lot. With government legislation and the increasing likelihood of RSI lawsuits, good quality chairs that offer most, if not all of the features described are now available at good prices. You don’t have to spend £600 or more, but you can. Don’t assume that more cost equals better chair. This is not always the case. My own chair cost £300 in 1994. The nearest thing I can find to it now is about £1000. I view it as money well spent, as other chairs I have sat in have caused me no end of posture problems and pain.

Sadly, many organisations use furniture as a means of stating authority. Which usually translates into the people doing the software having a poor quality chair, often with no arms. Senior staff get chairs with arms (they are valued so much!), and managers get decent chairs. This is an archaic way to view the workplace. Why these organisations don’t value their prize assets (their staff) more highly I do not understand.

The organisations I have seen do this, always lose the good staff. They realise what their employer thinks of them and leave because they know their own strengths and abilities. I digress, but if you are an employer and you are reading this, think about it, then go out and buy some great chairs for your staff.

What should I buy?

I don’t recommend heading down to your local Best Buy or IKEA, or buying chairs from the printer paper company’s catalogue. They do sell “office chairs” but they aren’t what I’d sit on, and I wouldn’t expect you to sit on them if you were working for me. Your body is the most valuable thing you own, and you probably didn’t go cheap when you purchased your workstation/laptop, so why would you do that when looking after the most valuable thing you own?

I can’t recommend the people that sold me my superb chair, as they are sadly no longer in business, but Posturite comes close to their ethos and design expertise. This isn’t a recommendation to buy from them, but an indicator of what you should be looking for. If they take your body measurements and then offer you chairs based on your dimensions that’s what I’d go with. Even better if they build chairs for you based on your dimensions (that’s how I got the chair I have – they wouldn’t sell me the chair without me completing a form so they knew my body dimension).

Also, don’t assume more expensive is better. I would never buy an Aeron. So much wrong with that chair design – it fails many of the criteria listed above.


Now that we’ve got the chair set up to suit your height and dimensions, we need to set up your desk. This is simpler than the chair.

  1. Sit at your desk with the chair adjusted correctly for your height. With your arms by your side, bend your arms at the elbow so that your lower arms are horizontal. Where your hands are is where the keyboard or textbook should be. That means the desk should be at a suitable height to allow this.

  2. If the desk is too low, then get some bricks and prop the desk up, or hire a carpenter to make some wooden supports to put under the desk.

  3. If the desk is too high, then you can either shorten the desk legs, purchase a new desk, or raise your chair seat height and get a foot support. If you do choose to raise the seat height (in my opinion the worst solution), you must get appropriate foot support.


Get an ergonomic keyboard (that doesn’t mean a ‘happy hacking’ style keyboard). The Microsoft natural keyboard is good (although the modern ones have a stupid cursor key layout). Other vendors also supply split keyboards. Some vendors (Maltron etc) supply completely different layout keyboards that are apparently very good. These are very expensive as not many are sold per year. I have one, but you need to use these all the time without returning back to QWERTY keyboards. As I have too many computers, I haven’t managed to do this.

Sitting at your newly adjusted desk on your shiny new chair, we can see how your keyboard should be set up.

  1. Roll your sleeves up so that you can see your forearm and wrists.

  2. Place your hands on your keyboard in the ‘home’ position (where your hands naturally go).

  3. Looking at your arms and hands from above (i.e. looking at the back of your hands), you arm and hand should be in line, with no bend at the wrist. You will find this much easier to acheive with a split or egonomic keyboard.

  4. Looking at each arm in turn, examine your arm and hand position from the side. Your hand should be level with your arm, and should not bend down or bend up at the wrist. If your wrist is bent his maybe caused by the chair/desk combination not being correctly adjusted, or because you have learnt to type like this.


Find a mouse you like, or try a trackball. Some people get on with trackballs very well. I am right handed but use a mouse in my left hand. Experiment, try new options. Trackpads (such as on Dell notebooks) are useful. Experiment with using more than one pointing device (a mouse and a trackpad, or a trackpad and trackball) so that you can vary your hand use.


With your chair and desk adjusted, we can adjust your monitor position appropriately. Sitting in your chair, the top of the visible portion of the monitor image should be roughly at eye level. Taking a 10′ or 11′ degree angle downwards from your eye position to the monitor should bring you to the bottom of the visible portion of the monitor image. Move the monitor further away from you or closer to you until this is acheived.

You may need to prop the monitor up on blocks to get the monitor the appropriate height. I have used (at different times) shoe boxes, redundant loud speakers and bricks for this task. You can also purchase hydraulic arms to move the monitor to a height suitable for you.


If your employer will not provide you with a chair, desk, monitor and keyboard that provides you (*) support, then I would think long and hard about what that says about their committment to you, your health and your future career prospects with them. Or, put another way, find a different and better employer.

(*) I mean you, not the others you work with – you are an individual, whats good for them isn’t necessarily good for you.


The exercises given here are based on the exercises given to me by my physiotherapist. The basis for these exercises is a treatment known as Adverse Mechnical Tension.

All stretches must be held for a minimum of seven real seconds, preferrably ten seconds. The reason I state real is because I mean 7 seconds on a clock, not seven seconds the way people count out loud (too fast). The reason the stretches must be held for this length is that the stretches are stretching nerve tissue. Nerve tissue is elastic and doesn’t actually stretch (without springing back into its original size) until it has been stretched for 7 seconds. So if you do these exercises and don’t stretch for at least 7 seconds, you are wasting your time and doing yourself no good. Please re-read the previous sentence.


These exercises are the exercises that I used to help recover from RSI as part of a treatment regime. I am not a trained physician or medical practioner, so any advice here is my description of the exercises given to me by my physiotherapist. You use these exercises at your own risk. If in any doubt about the validity of these exercises with respect to your physical health, consult a trained physician, physiotherapist or other appropriate medical authority.

If any exercise causes you pain, stop doing the exercise immediately. Try a different exercise.


The exercises given here are intended to help you regain your range of movement and improve your posture. The exercises should not cause you any more pain than you are presently experiencing with your RSI. If any exercise does cause you pain, stop doing that exercise and move on to a different exercise. As your health improves you can revisit any exercises that you had to skip.

The exercises can be done in any order, although you may find that you have a preferred order to do the exercises in. I tend to do all standing exercises, followed by all sitting exercises, followed by all floor exercises.

Good times to exercise are in the morning before you start work, in the evening after work, and before you go to sleep. Additionally you may find doing these exercises at work in your lunch break helpful. Work colleagues may find it unusual to see someone doing these exercises. Dont let that put you off. If you can find somewhere private to exercise that is usually better.

Whilst doing the standing exercises, emphasis is to be put on standing correctly, shoulders back (where they should be) and no slouching. However, don’t lock your knees, don’t stand on tip toes, or with flat feet (ankle collapsed inward). Your feet should be flat on ground, at shoulder width.

You will notice that most of these exercises do not work directly on your hands or arms. That is correct and intended. Your body is a complex machine, with levers (bones) and pulleys (tendons). These exercises are designed to increase range of movement and to also increase muscle strength. The lying down exercises increase the strength of your stomach muscles.

In an ideal world I’d have images and video clips to demonstrate how to do these exercises. I was persuaded to put this article together after chatting with Christian Graus (WDJ Author) about my experience with RSI. I haven’t had time to get any photos scanned or videos made. I will produce these in due course and put them here with the appropriate exercise.

Touch the ceiling

Stand up straight, with your arms at your side. Do not slouch. If in doubt look in a mirror and make sure you are not slouching. Whilst breathing in, raise your hands from your sides to above your head as if trying to touch the ceiling. When you are doing this, your aims should raise to your sides, not in front of you. When your arms are above you pointing at the ceiling, you should stretch your arms to the ceiling. Do not stretch your hands. The stretch should end at your wrists. Wait for 7 seconds, and lower your arms (reverse of previous raise, your arms should not go in front of you) whilst breathing out.

Its important to breath in and hold your breath whilst stretching as this improves the stretch. Make sure you can stretch and have your arms straight. If the ceiling is too low and you can’t do this, find a different room or go outside.

Repeat this exercise 10 times with a short break between each stretch.

Touch your toes

Whilst doing this exercise, be sure to use your stomach muscles to support yourself as you bend, otherwise too much strain will be placed on your back and you may hurt yourself.

Stand up straight, with your arms at your side. Do not slouch. If in doubt look in a mirror and make sure you are not slouching. Lift your hands above your head, arms pointing straight up. Now start to bend over until you can bend as far as you can, attempting to touch your toes. Do not force it. Wait for 7 seconds and straighten up.

Repeat this exercise 10 times. Each time you do this you should be able to stretch further. Do not bend your legs.


Stand up straight, with your arms at your side. Do not slouch. If in doubt look in a mirror and make sure you are not slouching. With your arms straight, swing one arm forwards clockwise, and the other arm backwards. After a few rotations, reverse direction. Your arms should be 180′ out of phase.

Forward stretch

Stand up straight, with your arms at your side. Do not slouch. If in doubt look in a mirror and make sure you are not slouching. Clasp both hands together, interlocking your fingers. Place your hands in front of your chest and stretch your arms forward until you can stretch no further whilst your hands are clasped together. Hold the stretch for 10 seconds.

Repeat this exercise 10 times.

A variation is to turn your hands ‘inside out’ when at full stretch so that your wrists are one the outside of the stretch. Do not do this if it is painful.

Sit and twist

Find a typical table chair – i.e. one that is not on castors. Sitting upright on the chair (do not slouch), wrap your arms across your chest so that you have your right hand on your left shoulder and your left hand on your right shoulder. This is to get your arms out of the way. You are sitting down so that the next exercise does not twist you hips, but does twist your spine for the full length of your back.

Now turn to the left, turning as far as you can with your body and your head. Your legs should remain facing forward. By turning left, you are trying to look right around yourself so that you can see objects on your right handside. Turn as far as you can. Hold this for 10 seconds. Now repeat this exercise by turning to the right as far as you can, trying to see around yourself so that you can see objects on your left hand side. Hold this for 10 seconds.

Repeat these two twists. Repeat these two twists, for a total of 3 twists each way.

Typically after doing this exercise you will find that the touch the ceiling and touch your toes exercises are easier to do.

Sit and stretch

Find a typical table chair – i.e. one that is not on castors. Sitting upright on the chair (do not slouch). Lean forwards over your knees and try to touch the floor in front of your feet. Stretch as far as you can. Hold this for 10 seconds. Return to the sitting position.

Whilst doing this exercise you may get an unusual sensation (but not pain) in the base of your back as the stretch starts to work. My experience of this is that it means the stretch is working.

Repeat this exercise 3 times.

Typically after doing this exercise you will find that the touch the ceiling and touch your toes exercises are easier to do.

Punches and shoulder rolls

Stand up straight, with your arms at your side. Do not slouch. If in doubt look in a mirror and make sure you are not slouching.

A shoulder roll is where you roll your shoulder up, back, down, and forward to its original position. Shoulder rolls can be done either one shoulder at a time or both shoulders together. I was taught to do shoulder rolls one shoulder at a time, but have found then to be more effective if I do both together.

The exercise is to do ten shoulders rolls, then ten rolling punches, one with each arm, alternately.

Repeat this exercise 10 times. Then finish with another 10 shoulder rolls.

It is important to always start with shoulder rolls and always finish with shoulder rolls. This is because rolling punches pull the shoulder forward, and shoulder rolls pull the shoulder back. We want the shoulder position to be back. People with poor posture often have shoulders that are very far forward of where they should be. This exercise is designed to help put your shoulders back where they should be.

Finally, shoulder rolls also open up your sternum, which on many people is very inflexible, but which should be more flexible.

Prayer and twist

Stand up straight, with your arms at your side. Do not slouch. If in doubt look in a mirror and make sure you are not slouching. Place the palms of each hand together, with your finger tips touching, fingers pointing upwards (thumbs towards your body, little fingers away from your body). Your hands should be in front of your face. This will look similar to a Christian prayer position. Slowly lower your hands (whilst keeping them pressed together and in the prayer position) so that they are half way down your body. At this point your lower arms should be horizontal (or as close as you can get) and your hands should still be pressed together. If there is any pain or tightness, stop at that point. Some people can do this with their arms horizontal, others cannot.

At this point there is another optional part of this exercise. When your reach the point where your lower arms are horizontal, you can rotate your hands away from you body whilst keeping them pressed together. Some people can only rotate their hands a small distance, whilst others can rotate their hands so that they are almost pointing down. Hold this position for 7 seconds, then rotate your hands back to the upright position.

Repeat the whole exercise 3 times.

Lie on floor, lift legs

Lie on the floor, lying on your back with your hands at your side and your legs straight. Slowly lift your left foot about 10 centimetres off the ground. Hold this position for tens seconds, then lower your foot to the ground. Repeat this exercise with your right leg.

Repeat the whole exercise 3 times.

Sit ups

Lie on the floor, lying on your back. Now raise you head and body and try to touch your feet. Repeat three times. Be careful not to strain yourself whilst doing this exercise.

Repeat three times.

Press up that isn’t a press up

Lie on the floor, face down with your hands under your shoulders and your elbows by your sides, as if you were about to a press-up. Slowly raise your body until your arms are straight, whilst trying to keep your hips touching the floor. When your are unfit, your back will be stiff and you won’t be able to do this (your hips will lift off the floor). As you get fitter you will be able to do this (my father, at age 62 can do this, so I’m sure you can too!). Hold this position for 10 seconds. Now lower yourself to the starting position.

Repeat this exercise 3 times.

Panorama Theme by Themocracy