NGWS Tool Developers Guide

Late Breaking News

· Title: ICorDebugAppDomain::EnumerateAssemblies returns wrong assembly count.
It is not safe to use an in-process method to get the number of assemblies used by the managed executable that is being profiled after the first UnloadAssembly callback has occurred. The number returned is not correct and is generally bigger than the actual number of assemblies that are present.

WORKAROUND:
Keep internal counters to the profiler that will monitor the number of loaded assemblies at any point of the execution. For example, use a counter that is increased in the AssemblyLoadfinished callback and decreased in the AssemblyUnloadFinished callback. Remember that the profiler is not thread-safe, so you should perform a "thread-safe" increment or decrement of any counters in the callbacks.

• Title: Transition events in the profiler API.
  Unmanaged To Managed Transitions:
  
  The NGWS runtime calls UnmanagedToManagedTransition to notify the code profiler that a transition from unmanaged code to managed code has occurred. The functionId is always the ID of the callee, and the reason indicates whether the transition was due to a call from unmanaged into managed code, or a return from an unmanaged function called by a managed function.
  
  If the reason is COR_PRF_TRANSITION_RETURN, then the functionId corresponds to the unmanaged function, and will never have been JIT-compiled. Unmanaged functions are still associated with some basic information associated with them, such as a name and some metadata. Sometimes the functionId can be NULL (for example, when there are function pointers in It Just Works (IJW) programs).
  
  If the reason is COR_PRF_TRANSITION_CALL then the functionID corresponds to the managed function. Under certain circumstances the managed functionID will not have been JIT-compiled yet; it will be JIT-compiled exactly after the transition event occurs and before the enter event for that function.
  
  Managed To Unmanaged Transitions:
  
  The NGWS runtime calls ManagedToUnmanagedTransition to notify the code profiler that a transition from managed code to unmanaged code has occurred. The functionId is always the ID of the callee, and the reason indicates whether the transition was due to a call from managed into unmanaged code, or a return from a managed function called by an unmanaged function.
  
  If the reason is COR_PRF_TRANSITION_RETURN, then the functionId corresponds to the managed function. In that case the functionId should always have been JIT-compiled in advance.
  
  If the reason is COR_PRF_TRANSITION_CALL, then the functionId corresponds to the unmanaged function, and will never have been JIT-compiled. Unmanaged functions are still associated with some basic information, such as a name and some metadata. Sometimes, the functionID can be NULL (for example, when there are function pointers in IJW programs).

· Title: CORDBG: "x" command is not working properly

In certain cases when we are using the command "x" under CORDBG we are not getting correct matches. Specifically, we are unable to get any matches using wild characters after :: or . For example, in hello.exe assume you have 3 methods.

If you pass to CORDBG:

cordbg) x hello.exe!HelloNameSpace.HelloWorld*

you will get

hello.exe!HelloNameSpace.HelloWorld::.ctor

hello.exe!HelloNameSpace.HelloWorld::GetWho

hello.exe!HelloNameSpace.HelloWorld::Main

if we attempt a

(cordbg) x hello.exe!HelloNameSpace.HelloWorld::G*

we will get

No matching symbols found in module: hello.exe.

(cordbg) This behavior is known and will be addressed in a future release.

· Title: PROFILER: GetCurrentThreadID asserts when invoked from a RuntimeSuspendStarted callback

When the ConcurrentGC is enabled, we get an assert when we are invoking ICorProfilerInfo::GetcurrentThreadID(). There is no workaround that since the callback does not return the threadID and we need this information API to identify uniquely the EE suspension attempt.

· Title: PROFILER: Profiling with Autozap

Profiling with autozap has problems as far as the enter-leave events are concerned and it is recommended not to use the autozap option.

· Title: PROFILER: GetClassFromToken() returns wrong ClassID in certain cases

In the profiler we are most of the times guaranteed to receive DIFFERENT class ID for every class we are using. There is an excption to that general rule where we can actually receive different classID for the SAME class and it can only happen for __ComObject. The reason is INTEROP requires that there be a different EEClass for it for each appdomain so there can be a different vtable layout for each one of them. For that reason __ComObject class ID will need to be treated as a special case.

· Title: GUI SDK DEBUGGER: Display of values for "objects" in the locals window contains redundant (duplicate) info

It seems that when we are inspecting the value of an object we get duplicate information in the "locals", "this", or "watches" window. The fields of any particular object are displayed two times.

Assume that you have the following class inheritance:

class Class8 : Class7

{

public double class8Local;

public Class8(double a) : base((a+8.0)) /* constructor */

{

this.class8Local = a;

}

} //end of Class8

class Class9 : Class8

{

public double class9Local;

public Class9(double a) : base((a+9.0)) /* constructor */

{

this.class9Local = a;

}

} //end of Class9

Inspecting "this" under DbgUrt where this is an instance of class9 will result in the following:

this {ClassBase.Class9} ClassBase.Class9

- ClassBase.Class9 ClassBase.Class9

ClassBase.Class8 ClassBase.Class8 <<<< DUP INFO

ClassBase.Class7 ClassBase.Class7<<<< DUP INFO

class8Local 10.0 double <<<< DUP INFO

class9Local 0.0 double <<<< DUP INFO

- ClassBase.Class8 ClassBase.Class8

ClassBase.Class7 ClassBase.Class7

class8Local 10.0 double

class9Local 0.0 double

a 1.0 double

· Title: GUI SDK DEBUGGER: Unable to parse program arguments from the command line

The GUI SDK Debugger is unable to parse command line arguments from the command line. Assume you have a managed executable foo.exe that takes 2 arguments (arg1, arg2).

The VS SDK Debugger is able to start a debugging session from the command line, by typing:

DbgUrt foo.exe

But is not able to start a debugging session of the form:

DbgUrt foo.exe -arg1 -arg2

The workaround is to use the first syntax and then explicitly specify the arguments from the GUI window after DbgUrt gets activated.

· Title: IN-PROCESS DEBUGGING: ICorDebugAppDomain::EnumerateAssemblies returns wrong assembly count

It is not safe to use this in-process method to get the number of assemblies used by the managed executable that is being profiled. AFTER the first UnloadAssembly callback has occurred. The number returned is not correct and it is generally bigger than the actual number of assemblies that are present. The problem it is due to the fact that the internal data structures of the in-process debugger do not get updated properly. The issues related to the in-process debugging will be addressed in the next release.

A workaround it is to keep internal counters to the profiler that will monitor at any point of the execution, the number of loaded assemblies. For example, use a counter that gets increased in the AssemblyLoadfinished callback and decreased in the AssemblyUnloadFinished callback.

Remember that the profiler is not thread safe so you should perform an "thread safe" increment or decrement of the any counters in the callbacks.