As an experienced developer, you do not have bug. Never. At least on your computer. And when sometimes (so rarely that you can barely remember) a bug appears, it is never on your computer.
And in this case, it is a true hell to find at least where in your application the bug is (because as you never have bugs, you do not need to integrate an error log system).
The first solution can be to decline the responsibility with a “It works for me, you should have a problem with your drivers”.
But you can also try to locate it J
This article presents you some tips to find some information about a bug on a non-developer computer.
Using Visual Studio 2012
Ok, it is unusual but if your customer owns Visual Studio, you can use the powerful "Debug Installed App Package” menu:
Obviously, if the app package does not contain symbols you can get no really interesting information:
To really debug the application, you need to have access to the source code and you must incorporate the PDB (Program Database file that contains the symbols) when you generate the app package:
But as you must know, it is pretty rare when a Customer already has Visual Studio 2012 and your source code in his computer
DebugView is a member of the excellent Tools suite called “Sysinternals Suite” developed by Mark Russinovich:
This tool allows you to capture debug message send by applications so you don’t need a debugger to catch the debug output your applications generate.
Obviously, the prerequisite is that your applications generate debug output (System.Diagnostics.Debug.Write).
For instance, WorldMonger (a game I develop with some friends) has these lines of code:
System.Diagnostics.Debug.WriteLine("Starting WorldMonger"); System.Diagnostics.Debug.WriteLine("Launching Babylon engine");
And when I launch DebugView (using Administrator rights) on any computer running WorldMonger, here is the resulting window:
ProcessMonitor is another really useful tool of the “SysInternals Suite”. It allows you to monitor your processes in realtime and can give you tons of useful information in order to help you debug your applications.
By installing a virtual driver on top of the system, ProcessMonitor can track:
- Registry access
- Files access
- Network access
- Process and thread activity (access to Windows API)
You just have to set a filter Inside ProcessMonitor to track only your own application. For instance, I added the following filter to see what is going wrong with my game:
Then I have to launch my game and wait for the bug (in this case, my music is not played). Inside ProcessMonitor, I can see that the file I wanted to played is not found:
You can see the [NAME NOT FOUND] indicating that the file cannot be found (a typo in the name).
So using ProcessMonitor, you can track the activity of your application and use it to inspect every interaction between your application and the operating system.
The Event Viewer
Finally you can find some useful information in the event log dedicated to Windows 8 Metro applications. The log can be located right there:
\Applications and Services Logs\Microsoft\Windows\Apps\Microsoft-Windows-TWinUI/Operationnal