The Exception.ToString() method contains call stack information when the exception was thrown. However if the PDB files from the assemblies involved are available, this information also contains file names and line numbers at each level of the stack trace. Needless to say that this information can be very beneficial to the developer.
The CLR will look for the PDB files in the runtime working directory, which for most applications is the installation directory itself. However for windows services the working directory is the windows systems32 directory (For eg: C:\Windows\System32). So exceptions thrown in assemblies that are hosted in a windows service, the call stack rarely contains the file names and line numbers even when the right PDB files are available.
The working directory of a windows service can be changed using the following line:
1: Environment.CurrentDirectory = System.AppDomain.CurrentDomain.BaseDirectory;Once the working directory has been changed to the base directory, the CLR should pick up the right PDB files and the stack trace should contain line numbers.
Thanks alot, a very helpful post! I added the line just at the end of the service's constructor. After that in case of exceptions the service provided me with line numbers as intended.
ReplyDeleteWow! thanks ever so much for the help! That did the trick for me as well. Trying to troubleshoot a windows service is a pain enough without trying to sort through the cause of cryptic exceptions. First time through it nailed a MessageBox I forgot to change to a log writer object which was buried two class layers deep in a try/catch.
ReplyDelete