checking dte.Solution for null causes a System.AccessViolationException?

Question

checking dte.Solution for null causes a System.AccessViolationException?

Rudolf Meier 291

Hi

In my C# Visual Studio Extension (for 2017 and 2019 at the moment), I'm using this lines of code...

try
{
    if(dte.Solution != null)
        ... do something;
}
catch(Exception)
{ /*ok, in this case, I don't care*/ }

And... the problem is, that Visual Studio (2017 and 2019) crashes in this if-statement with an unhandled System.AccessViolationException ... why? (the debugger shows, that dte is a valid object, but Solution ... might not be... no idea if it is or not... even the debugger can't tell me... that's why I thought... try-catch is the solution?)

Rudolf

0 comments

1 answer

Your answer

Answer 1

Michael Taylor 61,221

DTE is a COM object. If you try to reference that COM object on a thread other than the one it was created on then bad things happen. In your specific case it is unclear where this code is being called from but if it isn't on the UI thread of VS then you'll get odd behavior like this. This is a total guess at this point given no other context. It is also dependent upon what type of extension you're building - package, addin, etc.

Rudolf Meier 291 Reputation points

2022-01-14T20:37:16.537+00:00

sorry, forgot to mention that... I have this in my function

ThreadHelper.ThrowIfNotOnUIThread();

and, it's of type "Microsoft.VisualStudio.VsPackage" (at least that's what is specified in the vsixmanifest)

... and. I know this is a COM object. Is there an other way in C#? I only know this one. Normally I'm writing my extensions in native C++.
Michael Taylor 61,221 Reputation points

2022-01-14T20:49:58.147+00:00
Where is the dte variable coming from? Normally after you confirm you're on the correct thread you'll then query for the DTE using code like this:

var dte = ServiceProvider.GetService(typeof(DTE)) as DTE;

This is assuming you have created an extension that derives from Package. ServiceProvider is defined as follows so it gets auto-imported by the addin framework.

[Import] public SVsServiceProvider ServiceProvider { get; set; }

Rudolf Meier 291

it's derived from AsyncPackage

[PackageRegistration(UseManagedResourcesOnly = true, AllowsBackgroundLoading = true)]
[InstalledProductRegistration("#110", "#112", "1.0", IconResourceID = 400)]
[Guid(MyPackage.PackageGuidString)]
[ProvideMenuResource("Menus.ctmenu", 1)]
[ProvideAutoLoadAttribute("<guid>", PackageAutoLoadFlags.BackgroundLoad)]
public sealed class MyPackage : AsyncPackage

and has a function

protected override async Task InitializeAsync(CancellationToken cancellationToken, IProgress<ServiceProgressData> progress)
{
    await this.JoinableTaskFactory.SwitchToMainThreadAsync(cancellationToken);
    await BrowserDialog.InitializeAsync(this);
}

and... the BrowserDialog.InitializeAsync looks like this

public static async Task InitializeAsync(AsyncPackage package)
{
    await ThreadHelper.JoinableTaskFactory.SwitchToMainThreadAsync(package.DisposalToken);

    OleMenuCommandService commandService = await package.GetServiceAsync((typeof(IMenuCommandService))) as OleMenuCommandService;
    DTE dte = await package.GetServiceAsync(typeof(DTE)) as DTE;

    Instance = new BrowserDialog(package, commandService, dte);
}

... is it not allowed to store this dte value? Do I have to get it every time I use it?

Michael Taylor 61,221 Reputation points

2022-01-14T21:40:58.883+00:00

The DTE won't change for the life of your package so you can get it once. In my experience this generally happens in the InitializeAsync method of your package although you could wait until you actually need it.

It appears that your initialize method is creating a singleton of BrowserDialog. Nothing in that code seems to indicate that there should be an issue, ignoring the fact that the solution may or may not even be loaded yet. You are switching to the UI thread twice but that should be harmless.

Are other properties on DTE set properly? Your try-catch should work fine in this case though as it would catch the exception and do nothing. If you're running this in the debugger the debugger may break in but you can ignore that error and just go on.
Rudolf Meier 291 Reputation points

2022-01-19T15:32:50.593+00:00

ah... cool... it wasn't this extension... it was an other extension that caused visual studio to crash when my extension called a function on this interface... nice... :-) ... anyway... I learned a lot now (the most important one -> don't update extensions from others at the same time you are installing a new one from yourself... because then, it's impossible to know which causes the new errors that occur :-) )

Share via

checking dte.Solution for null causes a System.AccessViolationException?

1 answer

Your answer