SSMS Crashes When Creating or Editing SSIS Packages [closed]

Question

Problem started May 3rd. We are no longer able to import SSIS packages that have been modified by Visual Studio 2017.X into our SQL Integration Services (SQL version 2017 14.0.3023). SSMS Integration Services importation component (the GUI) keeps crashing! For any NEW packages or any Packages we modify with in Visual Studio 2017 x. We are able to import historical packages and Visual Studio 2012 packages.

Here is the error message from SSMS 17.5

Here is what we get when we used SSMS 17.6

Producing these events in the Windows Application event error log:

Fault bucket 2169157664500142207, type 5

Event Name: BEX

Response: Not available

Cab Id: 0

Problem signature:

P1: Ssms.exe

P2: 2017.140.17230.0

P3: 5aa77b02

P4: ucrtbase.dll

P5: 10.0.14393.2097

P6: 5a820b25

P7: 000891eb

P8: c0000409

P9: 00000007

P10:

Attached files:

\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERF5E0.tmp.WERInternalMetadata.xml

These files may be available here:

C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_Ssms.exe_5c8965b8776ba510b9bbdc96d6fefcc0aaa_ff38c945_2e8d1138

Analysis symbol:

Rechecking for solution: 0

Report Id: f99af3b2-3cda-40da-86ac-94c26a865ea5

Report Status: 0

Hashed bucket: 17946c34f35f49a32e1a65673658d07f

Error at 7:59:25

Faulting application name: Ssms.exe, version: 2017.140.17230.0, time stamp: 0x5aa77b02

Faulting module name: ucrtbase.dll, version: 10.0.14393.2097, time stamp: 0x5a820b25

Exception code: 0xc0000409

Fault offset: 0x000891eb

Faulting process id: 0x2ee4

Faulting application start time: 0x01d3e6e172bf41ca

Faulting application path: C:\Program Files (x86)\Microsoft SQL Server\140\Tools\Binn\ManagementStudio\Ssms.exe

Faulting module path: C:\Windows\System32\ucrtbase.dll

Report Id: 68608e7c-dbd8-48d8-bd5c-fc50eaadc804

Faulting package full name:

Faulting package-relative application ID:

Info at 7:58:03

Fault bucket 125730739576, type 5

Event Name: PerfWatsonVS12Data

Response: Not available

Cab Id: 1787729112124435524

Problem signature:

P1: PerfWatsonTcdb

P2: 0

P3: 0

P4: 0

P5: 0

P6:

P7:

P8:

P9:

P10:

Attached files:

\?\C:\Users\melisa.yale\AppData\Local\Temp\3\VSTelem.Out\201805081558_D15SVC_15.0.27130.2027_8f0864670b9a44af855ed6e41a660ed19604.tcdb

\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERAF37.tmp.WERInternalMetadata.xml

These files may be available here:

C:\ProgramData\Microsoft\Windows\WER\ReportArchive\NonCritical_PerfWatsonTcdb_688f135dd185f2a8133a474a2518efc6ce6cc4a_00000000_cab_246fb37d

Our Process:

We perform/make/implement our updates to the SSIS packages using Visual Studio (v 15.7.0) on the local SSIS SQL server (Microsoft Windows Server 2016 Standard) save the package to a file system drive not located on the server. We then open SSMS on the local SSIS SQL server (v 17.6) connect to the Integration Services on the Local (SSIS SQL Server) and import the File System Package into the “File System Stored Packages” using the GUI. i.e. Right clicking the “File System” note and selecting Import:

What we have tried (all of the below did not correct the issue):

• Multiple file folder permission changes
• Multiple package renaming and locations
• Multiple developer credentials for importing and design
• Multiple versions of SSMS 17x (17.6, 17.5, 17.4)
• Multiple versions of Visual Studio (15.7.0, 15.5.6)
• Restarting the SQL SSIS services
• Restarting the SQL Server services
• Rebooting the server
• Creating a new project and a new package in Multiple versions of Visual Studio (15.7.0, 15.5.6) and adding new packages with components.
• Modifying existing packages that were able to load prior to May 3rd
• Importing a newly created (and Modified) empty package.
• Adding the SSIS service AD Credential to the File Store shared directory
• Hours of google searches for SSIS crashing when importing and the error “Stub received bad data”
• Updating Visual Studio 15.7.0 with minor patch

Workarounds we have found:

• Developer creates and works on our OLD SQL 2008 server. Then we copy the Visual Studio v9 .dtsx package into our Visual Studio 15.7 project. Once we add the package as an “existing” package it upgrades the package. Now, if we do not perform any other modifications the package imports without any problems. So for the develop this works but is a pain. . because if there are any modifications they need to do it on the Visual Studio v 9 and re-import into Visual Studio 15.7 then Import it into The Integration services in SQL 2017.
• We can also just use the OLD Server (SQL 2008R2 and Visual Studio v9) for now until we get this fixed
• We also have a version of Visual studio 2013 (12.0.21005) that seems to be working fine. . . We can Modify/create and can import those .dtsx packages into the SQL Integration Services on the SQL 2017 server through the GUI in SSMS 17x
• We are able to “publish” the SSIS packages into the SQL server. However, our developer and the publisher sometimes are not the same person and the importing/publishing happens at a later date . Further the File System storage of SSIS packages is what the team is using at this point. We may migrate to the publication process but not right now. Unless we are forced to because of this problem.

Note: We are only able to import into the SQL Integration Services (SQL version 2017 14.0.3023) is the SQL Server Management Studio v17.6, 17.5, 17.4. The older SSMS’ cannot import into the newer SSIS service.

We think this problem is originating in Visual studio because we can create the package and import it using VS 9 but not (Since May 3rd) VS 15.7.0. . .If we create a NEW package. . and leave it "blank" it can be imported .. if we make the package with VS 9 and "upgrade it to VS 15 it is importable. . but the second we make "real" modifications it is unable to be imported? We also have an inclination that it might be our version of Integration Services that is unable to import the newer packages. Possibly an incompatibility issue?

We have checked and there were no “visible” changes/upgrades to Visual Studio since early March.

We also checked the server for Microsoft patches and updates for the period in question and found the following:

• On 5/3, System Center Endpoint Protection v4.10.209.0 was installed,
• on 5/4 Microsoft SQL Server Data-Tier Application Framework v14.0.3953.4 and
• Microsoft SQL Server 2017 T-SQL Language Service v14.0.17230.0 was installed.

Answer 1

SSMS 17.8 just came out today (June 21, 2018). Maybe this will fix the issue you guys reported.

The instructions outlined in the Microsoft article include specific steps to uninstall SSMS and VS 2015, verify the latest version of .NET Framework was installed, and several other checklist items, before installing SSMS 17.8.

I followed these steps and SSMS still crashes when adding a job that uses the File System Package Source on an SSIS package created using SSDT 2015 or later. So, with this glorious failure (thanks, Microsoft!), I will have to uninstall SQL Server 2017 and install a lower version. I hope the other people on this thread have better luck.

One thing to note: If you have Windows Server 2016 like I have, Microsoft says the following:

SSMS 17.X is based on the Visual Studio 2015 Isolated shell, which was released before Windows Server 2016. If you experience any issues with SSMS on Windows Server 2016, contact support. The support team determines if the issue is with SSMS, Visual Studio, or with Windows compatibility. The support team then routes the issue to the appropriate team for further investigation.