Category: Development

Turbo Debugger Symbols Viewer

By , March 6, 2020 12:48 pm

If you’re using Delphi or 32 bit C++ Builder your compiler/linker produces symbols in TDS format. TDS means Turbo Debugger Symbols – it’s an old naming convention from the days of the Turbo compilers.

There are occasions when it’s useful to know what’s inside the symbol file. Is the symbol name as I expected? Or is it mangled to something else? Is the symbol name in the debug info? If not, then maybe the compiler optimised that function out of existence (it does happen).

We’d already written a symbol file viewer for Visual Studio PDB files. It seemed logical to write a similar tool for TDS symbols. That tool is TDS Browser.

TDS symbols can be stored in the executable to which they relate, or in a separate TDS file. The 64 bit version of Delphi doesn’t provide an option for symbols in an external TDS file, which is odd, as no one wants to ship symbols with their executable. But hey, Embarcadero must have their reasons, right? As a result to view symbols with TDS Browser you can specify the TDS file or the executable file, either way we’ll load the symbols if they exist.

Symbol name mangling is different for 64 bit symbols, so we’ve provided an option to see the raw, unmangled symbol name for the occasions when you need that.

You can sort the symbols by any column, and reverse the sort by clicking the same column again. This is useful for finding symbols with source files – sort by filename. Select a symbol and we’ll show you the source code and line numbers if we can find the source code (not easy for source files that don’t have complete paths).

We provided options for resolving addresses into symbols for the 4 main use cases:

  • Crash at absolute address in DLL.
  • Crash at relative address in DLL.
  • Crash at symbol relative address.
  • Crash data from Windows Event Log in XML format.

The above options are on the Query menu.

If the crash address can be resolved into a symbol, the symbol is selected, and the relevant source code and line number information is displayed. A context menu also provides additional options for highlighing symbols and copying symbol related information to the clipboard.

Here’s a short video showing how to use TDS Browser.

An easier way to view crashes in the Windows Event Log

By , March 6, 2020 11:45 am

In a previous article I wrote about how to identify crashes in the Windows Event Log.

You need to use the Windows Event Viewer, inspect each entry looking for some keywords then decode the XML data to get the information you want. All a bit slow, tedious and error prone.

So we wrote a tool to do that for you: Event Log Crash Browser.

Event Log Crash Browser scans your event log looking for crash events, then picks out only the information that is useful:

  • The executable.
  • The DLL that crashed (if it did crash in a DLL, rather than non-DLL memory).
  • The exception code.
  • The offset into the DLL of the crash location (or the location in memory for non-DLL crashes).
  • We also read the version information from the DLL so that we can identify the company responsible for the DLL that crashed.

You can sort on any column, and filter by exception type, executable and DLL.

It’s a really easy way to see what failures are happening on your machine. A lot more convenient than Windows Event Viewer. Looking at this machine I can see that the Visual Studio compiler, linker and IDE crash from time to time. I can also see that the WMI provider service dies quite often from a heap corruption – this is a core bit of Microsoft technology that has problems. Most of the other failures are related to the software under development and test on this machine.

Identifying crashes with the Windows Event Log

By , February 12, 2020 4:43 pm

It’s an unfortunate and inevitable fact that while developing software sometimes your software will crash. This also happens, sometimes, hopefully very infrequently, in production code. Each time this happens Windows stores some information about each crash in the Windows Event Log, along with a multitude of other event information it logs.

In this article I’m going to explain two event log entry types which encode crashes, and how to read them. Then I’ll also introduce some tools that take the drudgery out of converting this information into symbol, filename and line number.

The Windows Event Log

The Windows event log can be viewed using Microsoft’s Event Viewer. Just type “Event Viewer” in the start menu search box and press return. That should start it. Crash information is stored in the sub category “Application” under “Windows Logs”. The two event sources that describe crashes are Windows Error Reporting and Application Error.

The image above shows a Windows Error Reporting event has been selected. The human readable form is shown below in the General tab. Although I say human readable, it really is unintelligible gibberish. None of the fields are identified and you have nothing to work with. The details tab isn’t any better – the raw data is present in text or XML form. Here’s the XML for the crash shown above.

<Event xmlns="">
    <Provider Name="Windows Error Reporting" /> 
    <EventID Qualifiers="0">1001</EventID> 
    <TimeCreated SystemTime="2020-02-12T10:09:34.000000000Z" /> 
    <Security /> 
    <Data>Not available</Data> 
    <Data /> 
    <Data /> 
    <Data /> 

There’s quite a bit of data in here, the purpose of each field implied, not stated. Towards the end is some information related to minidumps, but if you go searching for it, the minidump will no longer be present.

The format for Application Error crashes is different.

Windows Error Reporting

The event log data for a Windows Error Reporting event contains many fields that we don’t need if we’re just investigating a crash address. Each event starts with an <Event> tag and ends with an </Event> tag.

We need to correctly identify the event. Inside the event is a <System> tag which contains a tag with an attribute “Provider Name” set to “Windows Error Reporting”.

Once the event is identified we need to find the <EventData> tag inside the event. The <EventData> contains 14 <Data> tags. These tags are present:

  • 1. Timestamp.

  • 2. Number of data items.

  • 3. Information Type.

  • 4. Information Status.

  • 5. Unknown.

  • 6. Crashing executable.

  • 7. Executable version.

  • 8. Executable timestamp.

  • 9. Crashing DLL. This will be the same as 6 if the crash is in the .exe.

  • 10. DLL version. This will be the same as 7 if the crash is in the .exe.

  • 11. DLL timestamp. This will be the same as 8 if the crash is in the .exe.

  • 12. Exception code.

  • 13. Fault offset.

  • 14. Class. This may or may not be present

Information Type is normally “APPCRASH”. In this case we’re interested in tags 9, 12 and 13.

If Information Type is “BEX”, the data is different:

  • 1. Timestamp.

  • 2. Number of data items.

  • 3. Information Type.

  • 4. Information Status.

  • 5. Unknown.

  • 6. Crashing executable.

  • 7. Executable version.

  • 8. Executable timestamp.

  • 9. Crashing DLL. This will be the same as 6 if the crash is in the .exe.

  • 10. DLL version. This will be the same as 7 if the crash is in the .exe.

  • 11. DLL timestamp. This will be the same as 8 if the crash is in the .exe.

  • 12. Fault offset.

  • 13. Exception code.

  • 14. Class. This may or may not be present

Note that the order of the fault offset and exception code has been reversed compared to APPCRASH.

Of these tags we’re interested in tags 9, 12 and 13.

If we want to version the crashing DLL we also need tags 10 and 11.

Application Error

The event log data for an Application Error event contains many fields that we don’t need if we’re just investigating a crash address. Each event starts with an <Event> tag and ends with an </Event> tag.

We need to correctly identify the event. Inside the event is a <System> tag which contains a tag with an attribute “Provider Name” set to “Application Error”.

Once the event is identified we need to find the <EventData> tag inside the event. The <EventData> contains at least 12 <Data> tags, some of which may not be present, or which may be empty. These tags are present:

  • 1. Crashing executable.

  • 2. Executable version.

  • 3. Executable timestamp.

  • 4. Crashing DLL. This will be the same as 1 if the crash is in the .exe.

  • 5. DLL version. This will be the same as 2 if the crash is in the .exe.

  • 6. DLL timestamp. This will be the same as 3 if the crash is in the .exe.

  • 7. Exception code.

  • 8. Fault offset.

  • 9. Process id.

  • 10. Application start timestamp.

  • 11. Application path.

  • 12. Module path.

Of these tags we’re interested in tags 7, 8 and 12.

If we want to version the crashing DLL we also need tags 5 and 6. If 12 isn’t available, use 4.

Removing the drudgery

The previous two sections have described which fields to extract data from. If you’re doing this manually this is tedious and error prone. You have to select the correct values from the correct fields and then use another application to turn them into a symbol, filename and line number. Our tools DbgHelpBrowser and MapFileBrowser are designed to take a crash offset inside a DLL and turn it into a human readable symbol, filename and line number. But that still requires you to do the hard work of fishing the correct data out of the XML dump.

Now there is a better way, we’ve added an extra option to these tools that allows you to paste the entire XML data from a crash event and the tool then extracts the data it needs to show you the symbol, filename and line number.


Load the crashing exe (or DLL) into DbgHelpBrowser. This will cause the symbols to be loaded for the DLL (assuming symbols have been created and can be found). We’re not covering versioning the DLL as most likely you will have your own methods for this.

Choose the option Find Symbol from Event Viewer XML crash log… on the Query menu. The Event Viewer Crash Data dialog is displayed.

Paste the XML data into the dialog and click OK.

The main display will select the appropriate symbol in the main grid and display the relevant symbol, filename, line number and source code in the source code viewer below.


Load the MAP file for the crashing exe (or DLL) into MapFileBrowser. We’re not covering versioning the DLL as most likely you will have your own methods for this.

Choose the option Find Symbol from Event Viewer XML crash log… on the Query menu. The Event Viewer Crash Data dialog is displayed.

Paste the XML data into the dialog and click OK.

The main display will select the appropriate symbol in the main grid and display the relevant symbol, filename, line number and source code in the source code viewer below.


Windows Event Logs can be hard to read and error prone to use. However when paired with suitable tools you can quickly and easily turn event log crashes into useful symbol, filename and line number information to inform your debugging efforts.

Stdout redirection and capture

By , July 11, 2019 10:34 am

We were recently asked if Memory Validator could handle monitoring a program that took it’s input from a file and wrote its’ output to a file. As shown in the following example.

redirect.exe < input.txt > output.txt

Our tools could handle this, but it wasn’t obvious that they could. Also for interactive use there was no easy way to do this via the launch dialog, unless you were using Coverage Validator. We had to make changes to most of our tools so that they could do what Coverage Validator could do. All tools had a new diagnostic sub-tab added so that stdout data that was captured (an option) could be viewed.

In this article I’m going to explain how to launch a program that reads from stdin and/or writes to stdout using our tools. Although I’m talking about Memory Validator, these techniques apply to all our Validator tools.

There are four ways of doing this.

  1. Start your program from a batch file, putting the redirect of stdin and stdout in the batch file.
  2. Start your program from the launch dialog/wizard, specifying the input and output files on the launch wizard.
  3. Start your program from the command line, specifying the input and output files on the command line.
  4. Use the Memory Validator API to start Memory Validator from inside the target program.

Batch File

Using a batch file to do this is easy. Simply create your batch file in the form shown in the example below.

e:\redirect\release\redirect.exe < e:\test\input.txt > e:\test\output.txt

Save the batch file with a known name. In this example I’ll save the batch file in e:\test\redirectTest.bat. Then launch the batch file from Memory Validator (or another Validator tool). The first program launched by the batch file will be monitored.

Launch Dialog/Wizard

We modified the launch wizard and the launch dialog to include fields for an optional input file and an optional output file. We also added an option that would capture stdout so that you could view the output on the diagnostic tab.

This example shows the program testAppTheReadsFromStdinAndWritesToStdout.exe being launched, reading from e:\test\input.txt, and writing to reading from e:\test\output.txt.

The stdout capture checkbox has been selected. This will mean a copy of stdout will be captured and displayed on the diagnostic sub-tab stdout.

Command Line

For command line operation we need two new options -stdin and -stdout, each of which takes a filename for an argument.

There are two additional arguments that you can supply to tell Memory validator to ignore missing input files and missing output files: -ignoreMissingStdin and -ignoreMissingStdout.

memoryValidator.exe -program e:\redirect\release\redirect.exe 
                    -directory e:\redirect\release 
                    -stdin e:\test\input.txt 
                    -stdout e:\test\output.txt


You can use the Memory Validator API to start Memory Validator each time the target program is run. In that case just running the following command on the command prompt would cause Memory Validator monitor the target program redirect.exe.

e:\redirect\release\redirect.exe < e:\test\input.txt > e:\test\output.txt

To use the Memory Validator API with a particular application, the following steps outline the minimum steps required.

  1. Link to svlMemoryValidatorStub.lib (_x64.lib for x64)
  2. Link to svlMemoryValidatorStubLib.lib (_x64.lib for x64)
  3. #include “stublib.h”
  4. call startProfiler(); at the start of your program
  5. See documentation in the help file for more details.

For other Validator tools the library names will change. See the documentation (topic API) for the particular tool for details.


There are four ways you can work with stdin and stdout with our Validator tools.

You can work with batch files, launch interactively using the launch dialog/wizard, work from the command line, and use the Validator API.

Thread naming

By , June 19, 2019 7:21 pm

Multi-threading is becoming quite common these days. It’s a useful way to provide a responsive user interface while performing work at the same time. Our tools report data per thread where that is warranted (per-thread code coverage doesn’t seem to be a thing – no one has requested it in 17 years). In this article I’m going to discuss thread naming, OS support for thread naming, and additional support for thread naming that our tools automatically provide.

The Default Thread Display

Threads are represented by a thread handle and a thread id. Typically the thread id is what will be used to represent the thread in a user interface reporting thread related data. Thread ids are numeric. For example: 341. For trivial programs you can often infer which thread is which by looking at the data allocated on each thread. However that doesn’t scale very well to more complex applications. You can end up with thread displays like this:

Microsoft Thread Naming Exception

The WIN32 API does not provide any functions to allow you to name a thread. To handle this oversight, Microsoft use a convention that allows a program to communicate a thread name with it’s debugger. This is done via means of an exception that the program throws (and then catches to prevent it’s propagation terminating the application). The debugger also catches this exception and with the help of ReadProcessMemory() can retrieve the exception name from the program. Here’s how that works.

In your program

The exception code that identifies a thread naming exception is 0x406D1388. To pass the thread name to the debugger you need to create a struct of type THREADNAME_INFO (definition shown int the code sample), populate it with the appropriate data then raise an exception with the specified exception code. You’ll need to use SEH __try/__except to surround the RaiseException() call to prevent crashing the program.

typedef struct tagTHREADNAME_INFO
	DWORD	dwType;		// must be 0x1000
	LPCSTR	szName;		// pointer to name (in user addr space) buffer must be 8 chars + 1 terminator
	DWORD	dwThreadID;	// thread ID (-1 == caller thread)
	DWORD	dwFlags;	// reserved for future use, must be zero

#define MS_VC_EXCEPTION 0x406D1388

void nameThread(const DWORD	threadId,
                const char	*name)
	// You can name your threads by using the following code. 
	// Thread Validator will intercept the exception and pass it along (so if you are also running
	// under a debugger the debugger will also see the exception and read the thread name

	// NOTE: this is for 'unmanaged' C++ ONLY!

	#define BUFFER_LEN		16

	char		szSafeThreadName[BUFFER_LEN];	// buffer can be any size, just make sure it is large enough!
	memset(szSafeThreadName, 0, sizeof(szSafeThreadName));	// ensure all characters are NULL before
	strncpy(szSafeThreadName, name, BUFFER_LEN - 1);	// copying name
	//szSafeThreadName[BUFFER_LEN - 1] = '\0';

	ThreadInfo.dwType = 0x1000;
	ThreadInfo.szName = szSafeThreadName;
	ThreadInfo.dwThreadID = threadId;
	ThreadInfo.dwFlags = 0;

		RaiseException(MS_VC_EXCEPTION, 0, 
                               sizeof(ThreadInfo) / sizeof(DWORD_PTR), 
                               (DWORD_PTR *)&ThreadInfo); 
		// do nothing, just catch the exception so that you don't terminate the application

In the debugger

The THREADNAME_INFO struct address is communicated to the debugger in event.u.Exception.ExceptionRecord.ExceptionInformation[0]. Cast this pointer to a THREADNAME_INFO *, check the number of parameters are correct (4 on x86, 3 on x64), check the dwType and dwFlags are correct, then use the pointer in the szName field. This is a pointer inside the other process, which means you can’t read it directly you need to use ReadProcessMemory(). Once the debugger continues and this event goes out of scope, the ability to read the thread name no longer exists. If you want to read the thread name you must read it immediately, storing it for future use.

	if ((de->dwDebugEventCode == EXCEPTION_DEBUG_EVENT) &&
	    (de->u.Exception.ExceptionRecord.ExceptionCode == SVL_THREAD_NAMING_EXCEPTION))
#ifdef _WIN64
		if (de->u.Exception.ExceptionRecord.NumberParameters == 3)
#else	//#ifdef _WIN64
		if (de->u.Exception.ExceptionRecord.NumberParameters == 4)
#endif	//#ifdef _WIN64

			tni = (THREADNAME_INFO *)&de->u.Exception.ExceptionRecord.ExceptionInformation[0];
			if (tni->dwType == 4096 &&
			    tni->dwFlags == 0)
				void	*ptr = (void *)tni->szName;
				DWORD	threadId = tni->dwThreadID;

				if (ptr != NULL)
					char	buffer[1000];
					int		bRet;
					SIZE_T	dwRead = 0;

					memset(buffer, 0, 1000);
					bRet = ReadProcessMemory(hProcess,
								 1000 - 1,	// remove one so there is always a terminating zero

					if (buffer[0] != '\0')
						setThreadName(threadId, buffer);

Our tools support intercepting this mechanism so that we can name your threads if you use this mechanism.

The problem with this mechanism is that it puts the onus for naming the threads on the creator of the application. If that involves 3rd party components that spawn their own threads, and OS threads then almost certainly not all threads will be named, which results in some threads having a name and other threads being represented by a thread id.

CreateThread() And Symbols

In an attempt to automatically name threads to provide useful naming for threads without having to rely on the author of a program using thread naming exceptions we started monitoring CreateThread() to get the thread start address, then resolve that address into a symbol name (assuming debugging symbols are available) and use that symbol name to represent the thread. After some tests (done with our own tools – which are heavily multithreaded – dog-fooding) we concluded this was a useful way to name threads.

However this doesn’t solve the problem as many threads are now named _threadstartex().

_beginthread(), _beginthreadex() And Symbols

The problem with the CreateThread() approach is that any threads created by calls to the C runtime functions _beginthread() or _beginthreadex() will result in the thread being called _threadstart() or _threadstartex(). This is because these functions pass their own thread function to CreateThread(). The way to solve this problem is to also monitor _beginthread() and _beginthreadex() functions to get the thread start address, then resolve that address into a symbol name.


Starting with Windows 10, a name can be associated with a thread handle via the API SetThreadDescription(). The name associated with a thread handle can be retrieved using GetThreadDescription(). We use these functions to provide names for your threads if you have used these functions.

Un-named Threads

Some threads still end up without names – typically these are transient threads created by the OS to do a short amount of work. If the call to create the thread was internal to Kernel32.dll then CreateThread() will not be called by an IAT call and will not be monitored, resulting in the thread not getting named automatically. This isn’t ideal, but ultimately you don’t control these threads, which means you can’t affect the data reported by these threads, so it’s not that important.

Thread Naming Priority

We’ve made these changes to all our Validator tools and updated the user interfaces to represent threads by both thread id and thread name.

If a thread is named by a thread naming exception, SetThreadDescription(), or via a Software Verify API call that name will take precedence over any automatically named thread. This is useful in cases where the same function is used by many threads – you can if you wish give each thread a unique name to prevent multiple threads having the same name.

Here are some of the displays that have benefited from named threads.

Bug Validator

Memory Validator

Performance Validator

Thread Validator

Support for Menus in Visual Studio 2017, 2015, 2013, 2012, 2010

By , May 12, 2018 10:10 am

Visual Studio menu support

We’ve just added support for integrating tool menus into Visual Studio. This integration supports most of our tools. The menu only shows tools that are installed. Supported versions of Visual Studio are 2017, 2015, 2013, 2012, 2010.

Here’s what it looks like in Visual Studio 2017 (if you have all of our tools installed).

This means that most of our tools can be launched from within Visual Studio. If a solution is loaded, the tool you select will be started with appropriate options to process the startup project that is selected. For tools that support both x64 and x86 installation, on x86 platforms the x86 tool will be selected, on x64 platforms the x64 tool will be selected (if it was installed), otherwise the x86 tool will be selected.

For Thread Lock Checker and OutputDebugString checker the tools are given a list of the source files in the project. The source files are scanned for errors.

For DbgHelp Browser and PE File Browser the tools are given the executable that the project builds. The tools then display data about the executable and/or it’s debug information as appropriate.

For the various C++ Validators and .Net Validators, VM Validator, Exception Tracer and Page Fault Monitor, the tools are passed the same information that the Visual Studio debugger uses to start a program (program name, program arguments, startup directory). The tools then start the target program and monitor data according to which tool has been launched.

Exception Tracer

The eagle eyed will have noticed that in this list is the name of a tool that isn’t on our website (yet). Exception Tracer. This is a tool that has been in genesis for some time. It has transformed from an experimental debugger, into an experimental code coverage tool and now it’s an interesting view on the internal life of an application, from the point of view of the exceptions it throws. We’ve used Exception Tracer to analyse some unusual bugs that were almost impossible to analyse using a traditional debugger. We’ll be releasing this tool later this year. It will add to our growing list of free debugging and analysis tools on our website.

Cleaning up Visual Studio

By , March 19, 2018 12:33 pm

Why would you ever need a tool to clean up Visual Studio? Doesn’t Visual Studio have a built in “clean” mode that cleans your build directories?

Yes, it does, but that only cleans the file created by compiling and linking your software. Visual Studio also creates other files. How do you get rid of those files? Look them up, then search for them manually? That’s going to be time consuming.

Why would you even want to delete these extra files?

We’ve also seen Visual Studio crash from time to time. Sometimes it’s a plugin or extension gone astray, but other times it’s when you do something harmless like load a project or workspace or solution. What we found was that in many cases, just deleting the extra files would prevent future crashes.

So we wrote Visual Studio Project Cleaner to do that. The first version of the tool was written to work with Visual Studio 6, but we’ve updated it to also cleanup so of the files created by the newer versions of Visual Studio, Visual Lint and Visual Studio Project Fixer.

What type of file can we clean?

  • aps. Last Resource editor state.
  • bak. Backup file.
  • bsc. Source browser database.
  • dbg. Debugging information.
  • exp. Exports file.
  • idb. Minimum rebuild linker file.
  • ilk. Incremental linker file.
  • ipch. Incremental precompiled header file.
  • lastbuildstate. Build helper.
  • log. Build log.
  • map. Linker MAP file.
  • ncb. Intellisense database.
  • obj. Object file.
  • opt. Visual Studio options.
  • pch. Pre-compiled header file.
  • res. Compiled resource script.
  • sbr. Source browser information.
  • sdf. Intellisense database.
  • tlog. Depdenency file information.

We can also clean the following file types (these are disabled by default).

  • lib. Library file.
  • dll. Dynamic Link Library.
  • exe. Executable.
  • pdb. Program database.
  • old. Visual Studio upgrade files.
  • Visual Lint files in .visualint directories.
  • Visual Studio Project Fixer backup files (*.vcxproj-YYY-MM-DD-HH-MM-SS)

Clean your Visual Studio

We’ve been using Visual Studio Project Cleaner for years to clean unwanted files. It turns a tedious job into a simple and easy job.

Clean your files today with Visual Studio Project Cleaner.

Improving how we build projects and solutions

By , March 12, 2018 12:01 pm

The problem with Solutions

If you’re working with just one solution and the projects it contains Microsoft Visual Studio is a good tool for managing the builds. Except that it won’t necessarily build the projects in the right order, forcing you to make multiple build passes to get a built solution.

But what if you’re working with many solutions?

What if some of the projects in the solutions have identical project names, even though they are different projects? You can’t merge these into one mega solution so that you can build everything at once because the project names will clash.

Another problem with solutions is that the projects in the solution do not necessarily get built in the optimum order. A project that depends on another project may be built before that project dependency is satisfied. This forces you to build the solution multiple times until all dependencies are satisfied.

What if there was a better way to manage your builds? What if there was a better way to automate your builds?

Born from a real need

At Software Verify we have a code base of several million lines of C++, plus some C, assembler and C#. Looking at the Visual Studio Project Builder display I can see we have 28 solutions, with 217 projects, giving us a total of 962 different project configurations to complete a build. (The actual number is higher than this because it doesn’t include the legacy support solution and projects for Visual Studio 2002, because that can’t be installed on a 64 bit machine.).

This large number of projects and solutions includes every version of Visual Studio from Visual Studio 2017 to Visual Studio 6.

We needed to have a build tool that would allow us to reliably build a project, or solution, or a specific configuration of a project, regardless of version of Visual Studio or programming language.

All this would be done with one simple to use software tool that could be used interactively with a GUI or from the command line. The tool would provide visual feedback so that you could tell from 50 feet if the build was going pear shaped. The tool would also provide notifications so that you could forget about it and go do something else instead.

Visual Studio Project Builder

I’ve seen various solutions to this problem, lots of scripts, batch files, programs interacting. It works, kind of, but it’s all a bit of a mess, held together with string and duct tape in the best “make it work” seat of the pants “we haven’t got enough time” developer fashion.

That isn’t what I wanted. We’d already finished Visual Studio Project Fixer and I was very pleased with the results from that. I wanted the same “one tool” approach. We had the requirements, we knew what we needed to be able to build. We knew we had a decent test case (build our own tools) and we knew what a good tool would look like. As simple as possible.

That’s how Visual Studio Project Builder was born.

The basic capabilities are:

  • Automatically discover solutions and projects.
  • Optimise the build order.
  • Build, rebuild, clean project for any Visual Studio version from 2017 to 6.
  • Build individual project configurations, or variations based on project, solution and configuration.
  • Easily identify warnings and errors.
  • Easily filter warnings and errors.
  • Interactive GUI with real time build progress updating.
  • Can be run from a command line if desired.
  • Works on any Windows OS from Windows 10 through Windows XP.

A simple user interface

When performing a full build, full rebuild or full clean, a progress dialog is displayed, allowing the progress of the build to assessed at a glance, but with extra detail if you want it. You can tell from the colours on this dialog if a build is good, or bad, or has warnings, from 50 feet.

Behind the progress dialog is the main display, showing the status of every project configuration that can be built. Colours indicate status (good, warning, compiler error, linker error). A context menu provides access to options related to that project configuration, project or solution. For example:

  • Build all projects named “stubNonMFC” that have the configuration “Win32|Debug”.
  • Rebuild all projects that have the configuration “Win32|Release”.
  • Rebuild all projects in this solution that have the configuration “Win32|Release”.
  • Clean all projects named “tabserv”.
  • View build logfile.
  • View build command line passed to Visual Studio.

Some of the build options from the context menu cannot be done with Visual Studio, except by manual intervention for each project. When you span this across many solutions and projects this becomes very powerful and an incredible time saver.

Build notifications

Software developers perform a mentally taxing job. The last thing you want to add to their list is “Is the build done yet?”. To remedy this problem we have provided several (optional) notification methods:

  • Email when build is complete.
  • Text message when build is complete. Uses Twilio.
  • Speech message when build is complete.

My favourite is the last one. I can go and do something else, read a book, investigate a bug, work on something else, talk to someone, and when the build is done my computer talks to me: “Build Complete, Success”, or “Build Failure. 3 Errors”.

The email and text message notifications are intended for use when you are out of range of the computer talking to you.

We have delayed implementing carrier pigeon functionality until there is a proven market for it.

Does this compete with existing build solutions?

Does this compete with existing build solutions such as IncrediBuild?

No. Incredibuild speeds up builds of projects and solutions by distributing them on your local network.

Visual Studio Project Builder is all about getting projects built, in the right order, even though many toolsets may be in use. It all happens on the same machine. We’re hoping that Visual Studio Project Builder can work with build accelerators like IncrediBuild to speed things up.

Build your Visual Studio Projects

We’ve been using Visual Studio Project Builder in house for some time. We thought it was about time everyone else got a chance to use it. We’re making this available for free. Learn more about Visual Studio Project Builder.

Fixing Visual Studio project problems

By , March 5, 2018 2:51 pm

The productivity sink

Visual Studio is a very productive development environment. However, you can get Visual Studio into a state (for C++ and C developers, at least) where the compile and link both succeed, but when you go to run the executable Visual Studio annoyingly tells you that the build is out of date and would you like to build it?

This is a very frustrating experience. You go around and around in circles trying to work out what is wrong with the project that is causing this warning message to be displayed.

After some head scratching you’ll Google it and find solutions on numerous websites that tell you to do this, or that, or the other. The advice on some sites is consistent with the advice on other sites, some advice is not consistent. Then you find that some advice is for one version of Visual Studio, but you need to do something differently for a different version of Visual Studio.

It’s a mess. But you work out what you need to do, set about it and after tweaking a registry setting, running a tool to grab the output from OutputDebugString (or writing one if you couldn’t find a tool!), you now know which file is causing Visual Studio to tell you the build is out of date. Great!

Er, not so fast. The problem with this is Visual Studio only tells you about the first file that causes it to need to be rebuilt. Any other files aren’t listed, so you have to make the change then repeat the whole cycle. Slow!

“Crikey, that was a lot of effort, I hope that doesn’t happen again”, you think, or perhaps something a bit less polite. And then you remember you’ve got 10 more projects that behave like this, but you’d been ignoring that for a long time. But now you know how to fix it, but you can’t imagine putting in the effort for those 10 projects.

That was the situation we were in, except that just about every project we had (over 200 projects) had this problem. After tackling just one project I knew we had a choice:

  • Ignore the warnings.
  • Fix the warnings manually. Very slow. Lots of typing. Boring. Morale killer.
  • Find a way to automate the fixing of these problems.

Our engineering needs drove the decision.

Visual Studio Project Fixer

We decided to write a tool to make the hard bits of the above easy and to automatically discover what was wrong with a project file, then allow the user to choose which items to fix and which to leave alone. Plus an automatic mode that just fixes everything for you.

Things that can affect a project file are:

  • Missing files. The file exists on disk, but is not specified in the project.
  • Incorrect files. The file exists on disk, but not in the location specified in the project
  • Nonexistent files. The file doesn’t exist on disk, but is specified in the project.
  • Obsolete files. Files from older versions of Visual Studio.
  • .tlog files. Visual Studio file dependency files.

Some examples…

Missing file. You have a class defined in class.h and implemented in class.cpp. Only class.cpp is listed in the project file.

Incorrect file. A file is listed in the project as ..\svlCommonUI\class.h but is actually located at ..\svlCommon\class.h.

Nonexistent file. A resource file is specified that doesn’t exist. .\images\nonexistent.bmp.

Obsolete file. An old format help file from an early version of Visual Studio, carried over in Visual Studio project conversion.

A simple user interface

The image above shows the user interface after a scan of many projects has been performed. The summary display is shown, which lists an overview of the state of the projects and provides an option to automatically fix all the projects. If you click an individual project, the display changes to provided detailed information about that project.

There are four ways of scanning projects, providing for maximum flexibility in automating fixes or manually choosing each fix to apply.

  • Open a project.
  • Open a solution.
  • Open all projects in a directory (and sub-directories).
  • Open all projects in solutions in a directory (and sub-directories).

Having scanned some projects you can examine the results and choose to fix individual projects, or to fix all the projects that need fixing.

The default settings are to backup all project files before modifying them.

Diagnostic Information

It is possible that even with all the information provided by Visual Studio Project Fixer you may still wish to view the output from Visual Studio. Visual Studio 2015 and 2017 provide an option to show you this information. However for Visual Studio 2010, 2012 and 2013 you can enable diagnostic information to be sent via OutputDebugString(). This means that Visual Studio Project Fixer can intercept this information. All you need to do is enable it (from the Edit menu).

Then every time Visual Studio checks the status of a build, it’s output can be seen on the Visual Studio OutputDebugString tab.

Fix your Visual Studio Projects

We’ve been using Visual Studio Project Fixer in house for some time. We thought it was about time everyone else got a chance to use it. We’re making this available for free. Learn more about Visual Studio Project Fixer.

Changes to the first run wizard

By , February 15, 2018 2:41 pm

When you run one of our tools for the first time it displays the first run wizard.

The first run wizard takes you through the steps of configuring a few settings that are important to the tool your a using. Most of these settings are the same for each tool, although some of the first run wizards have settings pages that are specific to that tool.

We’ve just add a new page to the first run wizard. We’ve added the ability to configure the behaviour of the launch, inject and wait dialogs. The default behaviour is wizard. The behaviour can be modified from the Settings menu (formerly, Configure menu). Now this setting can also be set on the first run wizard.

The reason for adding this option to the first run wizard is because when we’ve done interactive debugging with customers we often notice that the user still has their Validator configured to use the launch wizard, rather than the more concise launch dialog. We thought there was a chance that some people don’t realise they can change the style of these dialogs/wizards.

Panorama Theme by Themocracy