SSMS crashes when checking for changes in Source Control 7.0

TonyStrileckis

I am on Source Control 7.0, using SSMS 17.9.  I have just 1 database (1.8 GB) where when I check for changes to be checked in, it crashes SSMS.  The error just says "SSMS has stopped working. Windows can check online for a solution to the problem and try to restart the program".  The problem is that we can't click on anything because it also freezes up the server that we run Red Gate Source Control on.  We then have to log off and back on the server to continue the rest of the check ins.

We updated to Source Control 7.0 earlier this year, and all the Working Base and Transient folders still show under Source Control 6 folder structure (which shouldn't be a problem).  I have tried unlinking and relinking this DB, (which ends up moving it under the Source Control 7 folder structure), and I still get the error and crash.

Several of our application vendors updated their databases a few months back with encrypted SP's, and now I have to uncheck the "Decrypt encrypted objects" under Comparison Options on each of them, but this is the only one where it crashes SSMS.  Is there something I can do to fix this, or somewhere in the Source Control logs that would show us what the problem is?
Please let me know if there is additional information that you need from me.
Thank you.

Alex B

Hi @TonyStrileckis,

The size of the database itself wouldn't cause an issue (unless you are trying to store a lot of it as static data) but rather the number of objects would be more likely to cause an issue.  Do any of the suggestions on this page help at all https://redgatesupport.zendesk.com/hc/en-us/articles/360007219153 ?

If you are changing and committing the comparison option to not "Decrypt encrypted objects" then I wouldn't have thought that would be the issue as it should be using the new option once committed.

If you set the logging option to "DEBUG" or "ALL" as described on this page and then recreate the issue there may be some info in the log file at %LocalAppData%\Red Gate\Logs\SQL Source Control

Also, having a look in the Event Viewer to see if there are any related messages may help.

Kind regards,
Alex

TonyStrileckis

Alex,
Thanks for your response.
I checked the link you provided and here are the answers to the steps on that page:

• I am already on SSMS 17.9 
• I'm not linking any static data tables. 
• I have already tried unlinking and re-linking (twice) 
• And the "Decrypt encrypted objects" option is already unchecked 
• Last option was that I unchecked the two options of "Indicate changed objects...every x seconds" and "Check for changes to static data", and then restarted SSMS.

After restarting SSMS, I tried again with that database, but it still crashes. 

I tried setting the logging option to "All", and a lot gets written to the logs, but nothing gets written to the logs after I select the server and database to check. 

I tried setting the logging option to "Debug", but again it doesn't capture anything relating to the crash.

Here's what gets written to the logs after setting the logging option to "Debug" (or to "All"), but it gets written as soon as I open SSMS, before I have selected a server or database to check in (and the same gets written to Event Viewer): 

• System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host Nothing else gets written to the logs after SSMS times out.

And Event Viewer just has the SSMS crash message.

• Faulting application name: Ssms.exe, version: 2017.140.17285.0, time stamp: 0x5b7c378f
• Faulting module name: clr.dll, version: 4.7.3062.0, time stamp: 0x5ab95217
• Exception code: 0xc00000fd
• Fault offset: 0x00157b77
• Faulting process id: 0x37ac
• Faulting application start time: 0x01d574992055fb96
• Faulting application path: C:\Program Files (x86)\Microsoft SQL Server\140\Tools\Binn\ManagementStudio\Ssms.exe
• Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
• Report Id: e6c70cf5-e08d-11e9-80d4-005056b43df2
• Faulting package full name:
• Faulting package-relative application ID:

Thank you, 
Tony

Alex B

Hi @TonyStrileckis,

Hmm, that 0xc00000fd error is a stack overflow.  What OS and SQL Server version is this with as well?

And how many objects are there in this database?  If needed would you be able to share the database (I would reach out via a support ticket with an https link to upload it if it was possible)?

Kind regards,
Alex

TonyStrileckis

Alex, 
I am using SSMS ver 17.9 on Windows Server 2012 R2.  SQL Server is installed, but not running on the server where I'm running Redgate SQL Source Control.  

This database has:

• 311 CHECK constraints,
• 23 Default constraints
  
• 3 FOREIGN KEY constraints
  
• 550 PRIMARY KEY or UNIQUE constraints
  
• 25 Scalar functions
  
• 5102 Stored procedures
  
• 67 System tables
  
• 7 Table functions
  
• 35 Triggers
  
• 559 User tables
  
• 20 Views
  

For a total of 6702 objects.  And this database is running on SQL Server 2012 SP3.

Unfortunately, I cannot share this database.

Thank you, 
Tony

TonyStrileckis

Alex, 
While checking on the number of database objects, I noticed that this database has a user-defined table type that is used in a function.  Don't know if they exist in any of our other databases. 

Would that cause any problems when checking in changes? 
And if so, how do I work around that?

Thanks, 
Tony

Alex B

Hi @TonyStrileckis,

Apologies for the delay in getting back to you on this, I thought I had replied, but it seems either I didn't submit it or something else went wrong!

I've gone over it again and I can't see anything wrong with having a user defined table type - or at least it isn't breaking anything for me.

I know it's been a little while now, so it would be good to see if a) this is still an issue in the latest version of SQL Source Control and b) if there is anything else different with that database than another.

Kind regards,
Alex

TonyStrileckis

Alex, 
Thanks for getting back to me.  Yes, this is still an issue.  I have SQL Source Control version 7.0.50.9962, having just updated to this version last week.
I don't see where there is anything different with this DB as to the others on this same server.
Is there anything in the SQL Source Control logs that I should be looking for?  Or that I can send you?  
Thanks, 
Tony

Tianjiao_Li

@TonyStrileckis

Since this is an issue with that specific database, it's very difficult for us to investigate without a copy of the database.

We can take a look of the verbose log in case there is anything useful and I'll reach out shortly by email.

Thanks.