How do we use the IDebugControl interface to wait for events?

            IDebugControl control = (IDebugControl)dataTarget.DebuggerInterface;                
            var hr = control.SetExecutionStatus(DEBUG_STATUS.GO);
            var waitStatus = control.WaitForEvent(DEBUG_WAIT.DEFAULT, uint.MaxValue);

This doesn't seem to work, Any ideas or documentation would be really great!

The HighDpiDemo has ClickOnce signing enabled with an invalid certificate which causes the build to fail.

1>------ Build started: Project: HighDpiDemo, Configuration: Debug Any CPU ------
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(4278,5): error MSB3482: An error occurred while signing: Failed to sign bin\Debug\app.publish\HighDpiDemo.exe. SignTool Error: No certificates were found that met all the given criteria.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

No replies on issues and no activity for months. Is the project abandoned?

From some experimentation with parallelizing various heap traversal algorithms, I'm hitting odd exceptions that are only happening in multi-threaded usage of the same ClrHeap. To be clear, I am using only the ClrMD interface, not the DbgEng one.

Before I try to narrow down the repro, is the ClrHeap designed for multithreaded access? For example, enumerating segments in two different threads, or calling NextObject in two different threads? I'm seeing exceptions in low-level parts, such as the DataReader.

@leculver

When I run "Anu CPU" or "x86" builds of TraceEvent project on a 64-bit box, at

...\TraceEvent\TraceEvent\30_MonitorLoads.cs:100

which is

session.EnableKernelProvider(KernelTraceEventParser.Keywords.ImageLoad | KernelTraceEventParser.Keywords.Process);

I get

System.Runtime.InteropServices.COMException was unhandled
_HResult=-2147024713
_message=Cannot create a file when that file already exists. (Exception from HRESULT: 0x800700B7)
HResult=-2147024713
IsTransient=false
Message=Cannot create a file when that file already exists. (Exception from HRESULT: 0x800700B7)
Source=mscorlib
ErrorCode=-2147024713
StackTrace:
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR(Int32 errorCode)
at Microsoft.Diagnostics.Tracing.Session.TraceEventSession.EnableKernelProvider(Keywords flags, Keywords stackCapture)
at TraceEventSamples.ModuleLoadMonitor.Run() in e:_Setups\dotnetsamples\dotnetsamples-master\dotnetsamples-master\Microsoft.Diagnostics.Tracing\TraceEvent\TraceEvent\30_MonitorLoads.cs:line 100
at TraceEventSamples.AllSamples.Run() in e:_Setups\dotnetsamples\dotnetsamples-master\dotnetsamples-master\Microsoft.Diagnostics.Tracing\TraceEvent\TraceEvent\00_AllSamples.cs:line 30
at TraceEventSamples.Program.Main(String[] args) in e:_Setups\dotnetsamples\dotnetsamples-master\dotnetsamples-master\Microsoft.Diagnostics.Tracing\TraceEvent\TraceEvent\Program.cs:line 9
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:

An attempt to continue execution (F11) brings

System.Exception was unhandled
_HResult=-2146233088
_message=The kernel provider must be enabled as the only provider and enabled only once.
HResult=-2146233088
IsTransient=false
Message=The kernel provider must be enabled as the only provider and enabled only once.
Source=Microsoft.Diagnostics.Tracing.TraceEvent
StackTrace:
at Microsoft.Diagnostics.Tracing.Session.TraceEventSession.EnableKernelProvider(Keywords flags, Keywords stackCapture)
at TraceEventSamples.ModuleLoadMonitor.Run() in e:_Setups\dotnetsamples\dotnetsamples-master\dotnetsamples-master\Microsoft.Diagnostics.Tracing\TraceEvent\TraceEvent\30_MonitorLoads.cs:line 100
at TraceEventSamples.AllSamples.Run() in e:_Setups\dotnetsamples\dotnetsamples-master\dotnetsamples-master\Microsoft.Diagnostics.Tracing\TraceEvent\TraceEvent\00_AllSamples.cs:line 30
at TraceEventSamples.Program.Main(String[] args) in e:_Setups\dotnetsamples\dotnetsamples-master\dotnetsamples-master\Microsoft.Diagnostics.Tracing\TraceEvent\TraceEvent\Program.cs:line 9
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:

I tried to figure out what is that file that "already exists" using procmon and filtering for both TraceEvent.exe and svchost.exe (in case it is an out-of-proc COM object) and found nothing: all CreateFile calls were with disposition "Open" (as opposed to create new)...

Any ideas?

I cloned the repository, opened the System.Numerics.Vectors.SampleCode project, and tried to run it. Received the following exception:

System.TypeLoadException was unhandled
Message: An unhandled exception of type 'System.TypeLoadException' occurred in mscorlib.dll
Additional information: Could not load type 'System.Numerics.Vector`1' from assembly 'System.Numerics.Vectors, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

This is on Windows 10 Build 10547, Visual Studio 2015 Community.

As an aside, does the sample also apply to .Net Native, or just to JIT compilation?

I think it is sensible to add clear deprecation warnings or a note of some kind in this repo. For example, the NuGet package for Microsoft.Diagnostics.Tracing.EventSource has not been updated since 2015.

Unfortunately, articles still link to this repo and if you Google for EventSource you will inevitably end up here, adding to the already confusing world of EventSource, EventPipes, ETW.

• create a pipeline for each project that builds it, verifies the build execution and publishes the build output as pipeline artifacts

Pipeline Foundation is a non-profit initiative with the sole purpose of giving back to the IT community by assisting OSS projects with DevOps implementations and best practices.

Built with ❤ by Pipeline Foundation.

In the example 40_LocalizedEventSource, the generated .man file only contains string table of en-US, and missing fr-FR.

Should the string table for 'fr-FR' be added manually?

• Dependabot alerts on updates for the project's dated and vulnerable dependencies and automatically creates PRs to easily update them

Pipeline Foundation is a non-profit initiative with the sole purpose of giving back to the IT community by assisting OSS projects with DevOps implementations and best practices.

Built with ❤ by Pipeline Foundation.

The exception occurs on the .NET 3.5 runtime but not the .NET 4.0+ runtime, when executing the line "source.Kernel.All += Print;" in the sample code, below. Neither the same code nor my code doing something very similar work.

static void DataProcessing(string dataFileName)
    {
        Out.WriteLine("Opening the output file and printing the results.");
        using (var source = new ETWTraceEventSource(dataFileName))
        {
            if (source.EventsLost != 0)
                Out.WriteLine("WARNING: there were {0} lost events", source.EventsLost);

            // Set up callbacks to 
            source.Clr.All += Print;
            source.Kernel.All += Print;
        ...

Here is the Exception:

System.InvalidCastException occurred
Message=Unable to cast object of type 'System.Action1[Microsoft.Diagnostics.Tracing.TraceEvent]' to type 'System.Action1[Microsoft.Diagnostics.Tracing.Parsers.Kernel.EventTraceHeaderTraceData]'.
Source=Microsoft.Diagnostics.Tracing.TraceEvent
StackTrace:
at Microsoft.Diagnostics.Tracing.Parsers.Kernel.EventTraceHeaderTraceData.set_Target(Delegate value)
at Microsoft.Diagnostics.Tracing.TraceEventParser.Subscribe(SubscriptionRequest cur, TraceEvent template, Object templateState, Boolean mayHaveExistedBefore)
at Microsoft.Diagnostics.Tracing.TraceEventParser.<>c__DisplayClassb.b__a(TraceEvent template)
at Microsoft.Diagnostics.Tracing.Parsers.KernelTraceEventParser.EnumerateTemplates(Func3 eventsToObserve, Action1 callback)
at WindowsEtwDataCollector.EtwDataCollector.RunKernelTrace(ConditionChecker shouldAbort) in C:\dev\vault\Vault\DataCollectors\WindowsEtwDataCollector\EtwDataCollector.cs:line 174
InnerException:

Microsoft.Diagnostics.Tracing.Parsers.Kernel.EventTraceHeaderTraceData
.. is derived from ...
Microsoft.Diagnostics.Tracing.TraceEvent

System.InvalidCastException occurred
Message=Unable to cast object of type 'System.Action1[Microsoft.Diagnostics.Tracing.TraceEvent]' to type 'System.Action1[Microsoft.Diagnostics.Tracing.Parsers.Kernel.EventTraceHeaderTraceData]'.
Source=Microsoft.Diagnostics.Tracing.TraceEvent
StackTrace:
at Microsoft.Diagnostics.Tracing.Parsers.Kernel.EventTraceHeaderTraceData.set_Target(Delegate value)
at Microsoft.Diagnostics.Tracing.TraceEventParser.Subscribe(SubscriptionRequest cur, TraceEvent template, Object templateState, Boolean mayHaveExistedBefore)
at Microsoft.Diagnostics.Tracing.TraceEventParser.<>c__DisplayClassb.b__a(TraceEvent template)
at Microsoft.Diagnostics.Tracing.Parsers.KernelTraceEventParser.EnumerateTemplates(Func3 eventsToObserve, Action1 callback)
at WindowsEtwDataCollector.EtwDataCollector.RunKernelTrace(ConditionChecker shouldAbort) in C:\dev\vault\Vault\DataCollectors\WindowsEtwDataCollector\EtwDataCollector.cs:line 174
InnerException:

I am not sure if the right term is dangerous or if it is desired behavior, but running the scripts under simd folder examples lead into this which broke everything that is hosted on desktopClr I suspect, that would be Visual Studio, Visual Studio Installer, Event Viewer, Powershell (these are the ones I've tried, but maybe there are more).
I am also not sure if this is a problem of the script or bug into the CLR maybe you guys can tell, but for now I'd rather open this issue to stay as a reference in case someone else is having similar issue.

Regards,
kuskmen

The CLRMD works great. As it shows the class instances stored in heap and we can able to get the instance count as well as size of each instance occupied in heap.

It would be better if we can try to get, where these objects are referencing(stack trace of the object).

Or any better way to get the instance info, where it is created from.

Kindly help me on this @leculver ....

We have been struggling to find why our logging infrastructure based on ETW and System.Diagnostics.Tracing.EventSource didn't work on .NET Framework 4.6.1 but worked on .NET Framework 4.6.2.

We have found today that, apparently, the problem was caused by our EventSource class (not the public name set in EventSourceAttribute) being just named "our namespace".EventSource.

Now we are trying to find that constraint in the documentation, with no success.

Can anyone confirm there was such an undocumented restriction in .NET Framework 4.6.1 (removed in .NET Framework 4.6.2) for EventSource subclass names?

Thank you very much.

Procdump -r creates a dump file without suspending the target process. Even for a very simple application, opening such a dump file with WinDbg + SOS works fine but fails with CLRMD. For example, ClrThread.StackTrace returns an empty collection of frames (whereas SOS produces a non-empty managed call stack).

There's a hardcoded reference in the CLRMD / DumpDict example

ClrRuntime runtime = CreateRuntime(@"D:\work\03_09_ml\ml.dmp", @"D:\work\03_09_ml");

In addition the comments immediately above also refer to files on someones harddrive.

The SIMD Sample talks about "downloading ryuJit preview" and "enabling jit", which was only relevant before RyuJit was released. As far as I know RyuJIT is the default (on x64 at least), so the instructions do more harm than good.
Please update the Readme to the current state of affairs. Unless the Sample itself is not relevant anymore, in which case it is better to remove the whole sample.

Aside: I'm really looking for how to deal with this for EventProvider+manifests, but it looks like EventSource and EventProvider work the same way in this specific scenario.

I can't find documentation anywhere (GitHub, MSDN, the works) on this. How would you approach implementing this method?

[Event]
public void Foo(string[] vals) { ... }

Or this one?

[Event]
public void Foo(int[] vals) { ... }

The ETW examples don't demonstrate this scenario. The string list necessitates the following "classic" manifest, for example:

<template tid="t23EFDE6D13D62A45">
    <data inType="win:UInt16" name="vals.Count" />
    <struct name="vals" count="vals.Count">
        <data inType="win:UInt16" name="vals.Length" />
        <data inType="win:UnicodeString" length="vals.Length" name="vals" />
    </struct>
</template>

This means that the buffer has to effectively follow that schema. My best guess is the following:

// 0: vals.Count
// 1: vals
EventData* descr = stackalloc EventData[2];

var valsLen = Math.Min(vals.Length, 20);
EventData* valsDescr = stackalloc EventData[valsLen * 2];

descr[0].DataPointer = new IntPtr(checked((ushort)vals.Length));
descr[0].Size = sizeof(ushort);

try
{
    // n + 0: val.Length
    // n + 1: val
    var valsLength = 0;
    for (var i = 0; i < vals.Length; i++)
    {
        var val = vals[i];
        if (val != null)
        {
            var ii = i * 2;
            var ij = ii + 1;

            valsDescr[ij].DataPointer = Marshal.StringToHGlobalUni(val);
            valsDescr[ij].Size = (val.Length + 1) * sizeof(char);

            valsDescr[ii].DataPointer = new IntPtr(checked((ushort)valsDescr[ij].Size));
            valsDescr[ii].Size = sizeof(ushort);

            valsLength += valsDescr[ij].Size;
        }
    }

    descr[1].DataPointer = new IntPtr(valsDescr);
    descr[1].Size = valsLength;

    // Write Event
}
finally
{
    for (var i = 1; i < vals.Length; i++)
    {
        var ptr = valsDescr[1 + i * 2].DataPointer;
        if (ptr != IntPtr.Zero) Marshal.FreeHGlobal(ptr);
    }
}

Any chance we could have the examples expanded to include int[] (fixed-length item arrays) and string[] (variable-length item arrays)?

1. Anchored Controls:

After moving from 125% scaling to 150%

After moving back:

2. DataFridView Headers:

After moving from 125% scaling to 150% gray area appear

The code:

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Globalization;
using System.Linq;
using System.Threading;
using Microsoft.Diagnostics.Runtime;

namespace ConsoleApplication1
{
    internal class MyClass
    {
        public static void Main()
        {
            var thread = new Thread(
                () =>
                {
                    while (true)
                    {
                        Console.WriteLine("123");
                    }
                });

            thread.Start();

            var pid = Process.GetCurrentProcess().Id;

            using (var dataTarget = DataTarget.AttachToProcess(pid, 5000, AttachFlag.Passive))
            {
                string dacLocation = dataTarget.ClrVersions[0].TryGetDacLocation();
                var runtime = dataTarget.CreateRuntime(dacLocation);

                while (true)
                {
                    Thread.Sleep(200);


                    foreach (var t in runtime.Threads)
                    {
                        var temp = t.BlockingObjects;
                    }

                    runtime.Flush();

                    GC.Collect();
                }
            }
        }
    }
}

When you run this code managed memory stays consitent, but native memory grows consistently. The detalization of most memory allocations below:

In my test run I got from 2.2 MB to 10.5 MB in 8 minutes, so I guess it is easily reproducible.

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

The sample https://github.com/Microsoft/dotnetsamples/blob/master/Microsoft.Diagnostics.Runtime/CLRMD/docs/WalkingTheHeap.md looks great. Unfortunately I do not get the numbers I am after. The problem is if that object has references back to some roots e.g. a static event handler which roots pretty much everything you get for all of your objects the same size which is not particularly helpful.
Is there a simple way to solve this?
E.g. EnumerateRefsOfObject could take a list of parent addresses which are known roots which should not be followed further to break this cyclic traversal.

• CodeQL is an open source code scanning tool for discovering vulnerabilities across a codebase

Pipeline Foundation is a non-profit initiative with the sole purpose of giving back to the IT community by assisting OSS projects with DevOps implementations and best practices.

Built with ❤ by Pipeline Foundation.

Currently, the DataTarget code doesn't recognize .NET 4.6 and fails with the following stack trace:

Unhandled Exception: Microsoft.Diagnostics.Runtime.ClrDiagnosticsException: This runtime is not initialized and contains no data.
   at Microsoft.Diagnostics.Runtime.RuntimeBase..ctor(DataTargetImpl dataTarget, DacLibrary lib)
   at Microsoft.Diagnostics.Runtime.Desktop.LegacyRuntime..ctor(DataTargetImpl dt, DacLibrary lib, DesktopVersion version, Int32 minor)
   at Microsoft.Diagnostics.Runtime.DataTargetImpl.CreateRuntime(String dacFilename)

I have been experimenting with my own write event overload but have found that when I introduce a string as shown below I end and try and read the event in PerfView or my own TraceEvent viewer it is corrupted.

Is anything missing here?

[NonEvent]
public unsafe void WriteEvent(int eventId, string arg1, double arg2, int arg3)
{
    if (IsEnabled() == false)
        return;

    if (arg1 == null)
        arg1 = "";

    fixed (char* chPtr = arg1)
    {
        EventData* descrs = stackalloc EventData[3];

        descrs->DataPointer = (IntPtr)((void*)chPtr);
        descrs->Size = checked(arg1.Length + 1 * 2);
        descrs[1].DataPointer = (IntPtr)(&arg2);
        descrs[1].Size = sizeof(double);
        descrs[2].DataPointer = (IntPtr)(&arg3);
        descrs[2].Size = sizeof(int);

        WriteEventCore(eventId, 3, descrs);
    }
}

Unless I'm missing something GetSourceLocationForOffset(Address nativeOffset) doesn't work.

For starters it doesn't even use the nativeOffset parameters that is passed in, so I think that this loop should actually look like this:

    if (map[i].StartAddress <= nativeOffset && nativeOffset <= map[i].EndAddress)
    {
        ilOffset = map[i].ILOffset;
        break;
    }

But even given that change, I don't think it'll work. The problem is that it tries to locate the matching IL offset, given a native code offset. But in some code I'm working on, I see that the IL offsets are overlapping:

    ILOffset - [StartAddress-EndAddress]
    FFFFFFFE - [241390-24139A]
           0 - [24139A-24139A]
           0 - [24139A-2413A1]
           6 - [2413A1-2413A3]
           7 - [2413A3-2413A8]
           C - [2413A8-2413B9]
          12 - [2413B9-2413BB]
          13 - [2413BB-2413C0]
          18 - [2413C0-2413C0]
    FFFFFFFD - [2413C0-241390]

So if 24139A was passed into GetSourceLocationForOffset(Address nativeOffset) it could come from within the range of either of the 2nd ([24139A-24139A]) or 3rd ([24139A-2413A1]) offset, what happens is that as soon as it finds a match it returns.

I've tried experimenting on getting the source offsets directly from the IL offset, without first going via a nativeOffset. It seems to be working, but it needed more changes to other code files, because it wasn't exposed, see mattwarren@16519ff

I'm thinking of designing a web dashboard to show useful information for debugging and was wondering if it will be possible to attach to a remote process either now or in the future?

Attaching to a process with more than 4GB heap works great. Opening a dump file from that process fails with the following exception:

ClrDiagnosticsException: Failure loading DAC: CreateDacInstance failed 0x80131c4f

WinDbg + SOS are perfectly capable of loading the dump file. The problem seems to lie with the ICLRDataTarget implementation that CLRMD provides (in DacDataTarget); specifically, with the DumpReader class adapted from the MDBG sample. It says in the comments that the class was designed to handle 4GB dump files only.

If I select the option to dump stack object (-dso) ClrStack reads from thread.StackBase to thread.StackLimit looking for "valid objects." The primary filter is
ClrType type = heap.GetObjectType(obj);
if (type == null)
continue;

I've found that the type is not null but looking at the object will cause problems for CLRMD. If I include an additional filter, life is good - at least better. The filter is:
if (!heap.IsInHeap(obj))
continue;

I'm trying to create this sample in VB.Net, in order to figure out how to take advantage of the DpiChanged event.

Steps to reproduce:

1. Create new VB.Net Winforms application, targeting 4.7
2. Add DpiAwareness key to app.config
3. Uncomment Win 10 supportedOS in app.manifest
4. In design mode for Form1, double-click the DpiChanged event entry to create the event body in the code behind.
5. Put a breakpoint on the event and run the app
6. Drag the window between two monitors with different Dpi scaling set.

The event will not fire until the "Enable themes" section is uncommented in the manifest, which is not required in the C# version given.

Any idea why this is?

Repro:
0. Win10 1709, VS2017, .NET 4.7.1

1. Have 2 monitors, with DPI 96 and 192 (for example). I use Surface Book + regular monitor
2. Set "Second screen only", logoff, login again, have system DPI at 96
3. Switch to "PC Screen only"
4. Open PerMonitorDemo.sln, confirm that Visual Studio uses raster scaling at this point.
5. Start app, Observe controls messed up.
   5.1. If you switch monitors to "Extend", the DPIChanged message arrives, and the app rescales properly.

I have some minidumps with limited data -- windbg says: "User Mini Dump File: Only registers, stack and portions of memory are available". Using SOS I can view file+line numbers in !ClrStack, example:

000000002029cab8 000000007766186a [HelperMethodFrame: 000000002029cab8] 
000000002029cba0 000007fe968163ff System.Reactive.Core.dll!Unknown
000000002029ee18 000007fef4f67b15 [HelperMethodFrame: 000000002029ee18] 
000000002029ef00 000007fe96c4fb96 System.Linq.Enumerable.SequenceEqual[[System.Double, mscorlib]](System.Collections.Generic.IEnumerable`1<Double>, System.Collections.Generic.IEnumerable`1<Double>, System.Collections.Generic.IEqualityComparer`1<Double>)
000000002029ef80 000007fe96c4ebcf Iit.TF.DataAccess.dll!Unknown [d:\Builds\88\4689\Sources\Source\DataAccess\Instruments\InstrumentComparer.cs @ 11]
000000002029f270 000007fe96c4e46a Iit.TF.DataAccess.dll!Unknown [d:\Builds\88\4689\Sources\Source\DataAccess\Instruments\InstrumentDataImporter.cs @ 70]

But using ClrMD, ClrRuntime.EnumerateModules() only returns mscorlib (so I can't load PDB files) and when walking the stack and outputting stackframe.DisplayString, I only get this:

System.Linq.Enumerable.SequenceEqual[[System.Double, mscorlib]](System.Collections.Generic.IEnumerable`1<Double>, System.Collections.Generic.IEnumerable`1<Double>, System.Collections.Generic.IEqualityComparer`1<Double>) 
Iit.TF.DataAccess.dll!Unknown 
Iit.TF.DataAccess.dll!Unknown 

If I attempt to use stackframe.GetFileAndLineNumber(), I get a ClrDiagnosticsException: "Failed to get PDB signature from module." which I assume makes sense because the modules are not there.

If I load larger dump files (same codebase) with full heap, the modules can be enumerated and the stack walk outputs the correct data.

Microsoft.Diagnostics.Runtime/CLRMD/Examples.sln references

• ClrMemDiag\ClrMemDiag.csproj
• ClrMemDiagExt\ClrMemDiagExt.csproj

but those are not present in the git repository (yet? :)
It is a bit annoying mostly when building from the command line.

After installing the VS2015 preview I can no longer attach to .NET 4.5 processes via Microsoft.Diagnostics.Runtime (neither the source version nor the nuget version work!)

Instead I get an exception "This runtime is not initialized and contains no data." when calling DataTarget.CreateRuntime

I assume this is because VS2015 updated the .NET runtime and CLRMD is no longer compatible, could someone update it maybe?

• GitHub Codespaces is a configurable cloud development environment available in your browser on GitHub or through Visual Studio Code.

Pipeline Foundation is a non-profit initiative with the sole purpose of giving back to the IT community by assisting OSS projects with DevOps implementations and best practices.

Built with ❤ by Pipeline Foundation.

If a provider references a nestandard1.5 dll, it gets dependencies from System.Runtime.dll 4.1.0.0.
Anyway other project may reference System.Runtime.dll 4.3.0.0 nuget package and adjust the bindingRedirect directives in order to match the version.

The problem is that eventregister makes a strong check against the references loaded in the secondary AppDomain and does not accept 4.3.0.0 at all.

I understood the behavior by looking the eventregister.exe in ILSpy, when the references written in the rsp file get loaded:

// Returns a string containing the assembly display name after policy has been applied.
string text = AppDomain.CurrentDomain.ApplyPolicy(args.Name);

try
{
    assembly = Assembly.ReflectionOnlyLoadFrom(assemblyFile);
}
catch { }
if (assembly != null && assembly.FullName == text)
{
    return assembly;
}

By comparing with "==" assembly.FullName == text includes the version and makes the bind fail.

The problem gets worse when in the same solution there are other projects that do require System.Runtime version 4.3.0.0. In fact on the build machine, depending on the order, the build may result in a successful or a failure depending on the last overwritten version of the System.Runtime.dll.

I tried to overcome the problem by extracting the 4.1.0.0 version into a separate folder and referencing directly with "add-reference, browse" and this works in Visual Studio 2015, but not on the build machine.

On the form I added System.Windows.Forms.ContextMenuStrip

this.contextMenuStrip1 = new System.Windows.Forms.ContextMenuStrip(this.components);
this.item1ToolStripMenuItem = new System.Windows.Forms.ToolStripMenuItem();
this.item2ToolStripMenuItem = new System.Windows.Forms.ToolStripMenuItem();

// 
// contextMenuStrip1
// 
this.contextMenuStrip1.Items.AddRange(new System.Windows.Forms.ToolStripItem[] {
this.item1ToolStripMenuItem,
this.item2ToolStripMenuItem});
this.contextMenuStrip1.Name = "contextMenuStrip1";
this.contextMenuStrip1.Size = new System.Drawing.Size(108, 48);
// 
// item1ToolStripMenuItem
// 
this.item1ToolStripMenuItem.Name = "item1ToolStripMenuItem";
this.item1ToolStripMenuItem.Size = new System.Drawing.Size(107, 22);
this.item1ToolStripMenuItem.Text = "Item 1";
// 
// item2ToolStripMenuItem
// 
this.item2ToolStripMenuItem.Name = "item2ToolStripMenuItem";
this.item2ToolStripMenuItem.Size = new System.Drawing.Size(107, 22);
this.item2ToolStripMenuItem.Text = "Item 2";

ContextMenuStrip not scales:

What need to do to context menu scales?

P.S. In this case System.Windows.Forms.MainMenu scales perfectly
Microsoft Windows [Version 10.0.16299.192]
.Net Framework 4.7

https://github.com/Microsoft/dotnet-samples/blob/6f2414148e33740c29116138e8bcef28364fafa8/Microsoft.Diagnostics.Tracing/TraceEvent/TraceEvent/10_SimpleEventSourceMonitor.cs#L95

There is a small chance that System.Environment.Exit can be called prior to the event handler being wired up. In this scenario, despite the huge amount of gracious and fantastic warnings about the importance of wiring up this event, the EventTraceSession will hang around after the program has exited. (Thank you to whoever spent the time to write up this fantastic example, by the way - it definitely pointed me in the right direction.)