I am pretty sure that UNSAFE forces preemptive, but I would also think that the security info is cached, just like it is for regular logins. Do you know what tSQLt.Info() does? Also, I do highly recommend switching over to DbFit, though I do understand that it is a bunch of work for a situation that doesn't happen often for you (based on your commend on Brent's answer)

The first thing it does is call some static CLR method SELECT tSQLt.Private::Info() - I get the same wait calling that directly. I'll just see what that does...

The definition of that is just return (SqlString) Assembly.GetExecutingAssembly().GetName().Version.ToString()‌​;

I wonder why tSQLt is set to UNSAFE. Based on the info from the S.O. answer linked to in Brent's answer, it only uses an external SqlConnection (and only sometimes), but that only requires EXTERNAL_ACCESS. The definition you just posted is just using Reflection and is SAFE functionality. Can you try change the PERMISSION_SET to EXTERNAL_ACCESS? Just to see the effect. Also, when selecting Private::Info() directly, does anything hang? I thought that was the issue more than the wait type.

@SolomonRutzky - Sorry I just noticed when looking in sys.assemblies it is in fact EXTERNAL_ACCESS - I mis-remembered that it is unsafe. And yes SELECT tSQLt.Private::Info() hangs indefinitely with that wait type

Is the DB set to TRUSTWORTHY ON or is it using a signature-based Login? I wonder if it will still work if we change the permission_set to SAFE? Are there any other SQLCLR functions, in tSQLt or otherwise, that you can call without there being this problem? I wonder if somewhere in that code it is doing Impersonation (which would require EXTERNAL_ACCESS).

The DB is set to trustworthy. I just tried turning off the wireless on the laptop and publishing and that succeeded. So that may be a sufficient workaround if this turns out to work reliably for me.

@MartinSmith Interesting. I guess the credential cache isn't used if it thinks that it can get to the domain controller? Just to test, would you be able to turn the wireless back on and then TRUSTWORTHY OFF? For your developer instance, is the service account Local System, your domain login, or a regular local account just for SQL Server?

@SolomonRutzky SQL Server 2014 Developer Edition uses the default account created NT Service\MSSQL$SQL2014. Local DB runs under my own account AFAIK. On further testing I think this is some problem that only shows up when I have the VPN connected so probably this Q is too localised and unlikely to be relevant to anyone else.

FYI - external access and unsafe that need to obtain a SID or impersonate something will most certainly have this wait type. Since this is CLR and calling out to WinNT API, it'll also be preemptive on the scheduler. If it's sitting on the scheduler forever, can you make a XE that looks for this and generates a stack dump? I can look at the calling stacks - no promises on an RCA though.

@MartinSmith But so far I wouldn't think that this is too localized. It is worth, I think, getting a better understanding of why it is even reaching out to the OS as it could have performance implications when it isn't hung. Unless you are using the 1 external command function, can you try setting it to SAFE and see what happens?

@SeanGallardy-Microsoft I found the code at github.com/tSQLt-org/tSQLt/tree/master/tSQLtCLR/tSQLtCLR and as far as I can see, it doesn't make any external calls at all.

@SolomonRutzky It may not be calling out to anything explicitly, but when the impersonation is needed, that will call out to WinNT API. That's why I asked for a stack trace.