Windbg – Getting environment information from the target machine

This is a brief explanation about how to get information from the target machine with some examples.

Let’s suppose you already have opened the memory dump in your windbg. Let’s also suppose that you already setup the symbols path properly.
Ok, then.

If you want to find out the name of the target’s machine execute:
!envvar COMPUTERNAME

In case you want to know the user logged in the machine :
!envvar USERNAME

Now, you want to know the architecture of the current process:
!envvar PROCESSOR_ARCHITECTURE

and more…

Here you have for example a list of Standard Environment Variables you can experiment on:

http://ss64.com/nt/syntax-variables.html

==============================================

Enjoy debugging!

Debugging .NET optimized code

How to see the full content of the variables in Visual Studio if the binary is optimized or not built with full support for symbols.

Let’s suppose that we already have the symbols or pdb file of our dll when debugging under Visual Studio and you cannot check or examine some of the variable values.

The reason behind this issue is most probably that the dll is optimized or maybe it wasn’t built with full symbols and this means the debugger only has full access to some of the variables.

If you don’t want to re-compile for any reason you can use the next trick.

If the dll is MyFantasticDll.dll then you have to create another empty file named as MyFantasticDll.ini.

Open, fill and save it with

[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0


This would cause the JIT-compiler to not optimize the resulting machine code and the next time you want to see the values you will see them in Visual Studio.

So to make it work we need the three files:

                           MyFantasticDll.dll
                           MyFantasticDll.pdb (the symbols file necessary to debug)
                           MyFantasticDll.ini


and all of them need to be together in the same folder.

Take into account that the original dll could be placed in some folder under the GAC or a Temporary Folder.

To find out the exact location you may want to use the “Modules” tab in Visual Studio and check the “Path” column.

Here you have the source:

https://msdn.microsoft.com/en-us/library/9dd8z24x%28v=vs.110%29.aspx

======================================================

Enjoy debugging!