Writing a software for a Trader

During long months, I have been working on a Trader App. The screens consist of grids with interactions and calculated formulas. Initialy, the guy was working with Excel. Now, it’s in a Windows Forms application powered by a MDI (Multi Document Interface) infrastructure using C#, SQL Server and WCF. A lot of data are acquired from the database. But some are accessed by Web Services. Look at the screens:

 

 

Access violation and WinDBG

 

This month, I have written an article about debugging under Windows for french magazine Programmez.

The main topic talks about how to prepare your code for advanced debugging techniques. Take a routine:

public bool InitSession()

{

try

{

Log.Instance.Info("InitSession...");

//

// Do some work ...

//

return true;

}

catch (Exception ex)

{

Log.Instance.Error("InitSession failed", ex);

return false;

}

}

Because there are logging informations and exception handling and a return value for the function, it is easy to make debugging with this kind of stuff.

If your code does not contain logging informations, your last option is to use a system debugger : WinDBG.

WinDBG is redistributed under the Windows SDK or Windows DDK. Start WInDBG and attach the process you want to debug. The debugger attaches the process and put it in pause.

Launch the command go (g) and wait for it to be in an unhandled access violation case.

Load the “Son Of Strike” DLL which is SOS.DLL : .load C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll

When your exception comes, ask for the stack dump using this command: !DumpStack

And the miracle is coming : the name of the fault routine is the first line of the dump:

In my case, the faulting routine is SDRM.Services.Svc.CallReutersWSForGrid1().

Debugging is easy (or not so complicated) when you have the right tools.

Enjoy !