Home/ Questions/Q 8079027
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-05T15:59:01+00:00

I have a large project that executes without problem when not debugging (even when

  • 0

I have a large project that executes without problem when not debugging (even when running the debug build).

If I try to debug the project, when execution hits a certain MS CCR dependent library the debugger pauses execution:

disassembly of source

The call stack at this point appears as follows:

stack trace

This occurs even when “Debug”->”Exceptions…”->”CLR Exceptions” thrown and user-unhandled are both unchecked.

The problem appears to be happening in Microsoft.Core.Ccr.dll at Microsoft.Ccr.Core.TaskExecutionWorker.ExecuteTaskHelper(Microsoft.Ccr.Core.ITask currentTask) + 0x94 bytes since I upgraded the project to .net4.5 and added the latest version of Microsoft.Ccr.Core (4.0.261.0).

This is a major inconvenience to my debugging efforts as hitting these non-existent breakpoints means that other time-related parts of my project are almost impossible to debug correctly.

What could possibly be causing this behaviour and are there any options I’ve missed that might allow VS to ignore the problem?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    After a dotPeek decompilation of TaskExecutionWorker.ExecuteTaskHelper I see the following:

        if (!CausalityThreadContext.IsEmpty(threadCausalities) && 
         CausalityThreadContext.RequiresDebugBreak(threadCausalities))
      Debugger.Break();

    I can see why they did this (I have unhandled exceptions somewhere) but now they’ve been gobbled by CCR, and the info I can see in the debugger makes this code-defined breakpoint somewhat pointless.

    EDIT

    It seems that I had added Causalities with property BreakOnReceive = true to the Dispatcher. As such this is expected behaviour. I can’t see any possible use for this setting as the exceptions have been gobbled. Surely a better decision here would be to throw an exception rather than break the debugger. Hmmm…

    • 0