Odd debugger behavior with Interface and Generics on 64bit OS when toggling 'Prefer 32-Bit
Asked Answered
R

1

20

I have come across this odd behaviour: when my projects settings are set to Any CPU and Prefer 32-bit on a 64bit Windows 7 OS the .Net 4.5program below works as expected. If however I turn off Prefer 32-bit then when stepping through the program, I can see that the code never steps into the interface implementation - but also does not throw any errors.

I have distilled it down to its simplest form in the following console application:

namespace BugCheck
{
    interface IBroken
    {
        bool Broken<TValue> (TValue gen, Large large);
    }
    class Broke : IBroken
    {
        public bool Broken<TValue> (TValue gen, Large large )
        { return true; }
    }
    struct Large
    {
        int a, b, c;
    }
    class Program
    {
        static void Main (string[] args)
        {
            //32bit can step in. 64bit can't
            ((IBroken)new Broke()).Broken(1, new Large());
        }
    }
}

As expected, when toggling Prefer 32-bit the program will alternate between the .net 32bit assemblies and the 64bit assemblies - where it works as expected with the 32bit assemblies and "breaks silently" with the 64bit assemblies.

As suggested by @Athari it appears to be related to the size of the Large struct.

What am I doing wrong that is causing this behaviour?

Radiothermy answered 10/8, 2014 at 19:11 Comment(2)
Looks like a 4.0 debugger bug to me, the 2.0 debugger has no trouble with it. Nothing anybody here can fix for you, report this at connect.microsoft.comKilligrew
@HansPassant thanks, will follow that route -- just want to make sure I am not falling into the trap of assuming it a bug, if the bug is just my ignorance :) I Seemed to have trouble logging via the browser, so fell back on integrated feedback in VS ( so probably logged in incorrect location ) connect.microsoft.com/VisualStudio/Feedback/details/943122Radiothermy
C
1

For those that come across this question looking for a solution, to quote Tom from the Microsoft team:

This looks like it is related to a bug that is fixed in .NET Framework 4.5.2. We can verify that that the issue is related by disabling the Managed Return Value feature. I have posted instructions for doing this to the 'Workarounds' section.

This issue is caused by the code which gathers return values. It is possible to work around the issue by disabling Managed return values.

  1. Go to the System properties (Win8: WinKey+X, select ‘System’, Win7: Open ‘Properties’ from my computer)
  2. Advanced System Settings
  3. Environment Variables…
  4. Click ‘New’ and add
    • Name: VSDebug_DisableManagedReturnValue
    • Value: 1

If disabling Managed Return Values works around the issue, the fix for this issue is in .NET Framework 4.5.2. This can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=42642. Installing 4.5.2 is all that is needed to fix the issue.

Cabin answered 22/8, 2014 at 1:8 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.