创建或编辑 SSIS 包时 SSMS 崩溃

Question

问题始于 5 月 3 日。我们无法再将已由 Visual Studio 2017.X 修改的 SSIS 包导入到我们的 SQL 集成服务（SQL 版本 2017 14.0.3023）中。SSMS 集成服务导入组件（GUI）不断崩溃！对于任何新包或我们在 Visual Studio 2017 x 中修改的任何包。我们能够导入历史包和 Visual Studio 2012 包。

这是来自 SSMS 17.5 的错误消息

这是我们使用 SSMS 17.6 时得到的结果

在 Windows 应用程序事件错误日志中产生这些事件：

故障桶2169157664500142207，类型5

活动名称：BEX

回应：不可用

驾驶室 ID：0

问题签名：

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：

附加的文件：

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

这些文件可能在此处可用：

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

分析符号：

重新检查解决方案：0

报告 ID：f99af3b2-3cda-40da-86ac-94c26a865ea5

报告状态：0

哈希桶：17946c34f35f49a32e1a65673658d07f

7:59:25 出错

错误的应用程序名称：Ssms.exe，版本：2017.140.17230.0，时间戳：0x5aa77b02

错误模块名称：ucrtbase.dll，版本：10.0.14393.2097，时间戳：0x5a820b25

异常代码：0xc0000409

故障偏移：0x000891eb

错误进程 ID：0x2ee4

错误的应用程序开始时间：0x01d3e6e172bf41ca

错误的应用程序路径：C:\Program Files (x86)\Microsoft SQL Server\140\Tools\Binn\ManagementStudio\Ssms.exe

错误模块路径：C:\Windows\System32\ucrtbase.dll

报告 ID：68608e7c-dbd8-48d8-bd5c-fc50eaadc804

错误包全名：

错误的包相关应用程序 ID：

信息时间 7:58:03

故障桶 125730739576，类型 5

事件名称：PerfWatsonVS12Data

回应：不可用

驾驶室编号：1787729112124435524

问题签名：

P1：PerfWatsonTcdb

P2：0

P3：0

P4：0

P5：0

P6：

P7：

P8：

P9：

P10：

附加的文件：

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

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

这些文件可能在此处可用：

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

我们的流程：

我们在本地 SSIS SQL 服务器（Microsoft Windows Server 2016 Standard）上使用 Visual Studio (v 15.7.0) 执行/制作/实现对 SSIS 包的更新，将包保存到不在服务器上的文件系统驱动器中。然后，我们在本地 SSIS SQL 服务器 (v 17.6) 上打开 SSMS，连接到本地 (SSIS SQL Server) 上的集成服务，并使用 GUI 将文件系统包导入到“文件系统存储包”中。即右键单击“文件系统”注释并选择导入：

我们尝试过的（以下所有内容均未解决问题）：

• 多个文件夹权限更改
• 多个包重命名和位置
• 用于导入和设计的多个开发人员凭据
• SSMS 17x 的多个版本（17.6、17.5、17.4）
• 多个版本的 Visual Studio（15.7.0、15.5.6）
• 重新启动 SQL SSIS 服务
• 重新启动 SQL Server 服务
• 重新启动服务器
• 在多个版本的 Visual Studio（15.7.0、15.5.6）中创建一个新项目和一个新包，并添加带有组件的新包。
• 修改能够在 5 月 3 日之前加载的现有包
• 导入新创建（和修改）的空包。
• 将 SSIS 服务 AD Credential 添加到文件存储共享目录
• 导入时谷歌搜索 SSIS 崩溃的小时数和错误“存根收到错误数据”
• 使用小补丁更新 Visual Studio 15.7.0

我们发现的解决方法：

• 开发人员创建并在我们的 OLD SQL 2008 服务器上工作。然后我们将 Visual Studio v9 .dtsx 包复制到我们的 Visual Studio 15.7 项目中。一旦我们将包添加为“现有”包，它就会升级包。现在，如果我们不执行任何其他修改，则包导入没有任何问题。所以对于开发来说，这是可行的，但很痛苦。. 因为如果有任何修改，他们需要在 Visual Studio v 9 上进行并重新导入 Visual Studio 15.7，然后将其导入 SQL 2017 中的集成服务。
• 我们现在也可以只使用 OLD Server（SQL 2008R2 和 Visual Studio v9），直到我们解决这个问题
• 我们还有一个似乎运行良好的 Visual Studio 2013 (12.0.21005) 版本。. . 我们可以通过 SSMS 17x 中的 GUI 修改/创建并将这些 .dtsx 包导入到 SQL 2017 服务器上的 SQL 集成服务中
• 我们能够将 SSIS 包“发布”到 SQL 服务器中。然而，我们的开发者和发布者有时不是同一个人，导入/发布发生在较晚的日期。此外，团队目前正在使用 SSIS 包的文件系统存储。我们可能会迁移到发布过程，但不是现在。除非我们因为这个问题而被迫。

注意：我们只能导入 SQL 集成服务（SQL 版本 2017 14.0.3023）的是 SQL Server Management Studio v17.6、17.5、17.4。较旧的 SSMS 无法导入到较新的 SSIS 服务中。

我们认为这个问题源于 Visual Studio，因为我们可以使用 VS 9 创建包并导入它，但不能（自 5 月 3 日起）VS 15.7.0。. .如果我们创建一个新包。. 并将其保留为“空白”它可以导入.. 如果我们使用 VS 9 制作包并“将其升级到 VS 15 它是可导入的..可能是我们的 Integration Services 版本无法导入较新的包。可能是不兼容问题？

我们已经检查过，自 3 月初以来，Visual Studio 没有“可见”的更改/升级。

我们还检查了服务器上有问题期间的 Microsoft 补丁和更新，发现以下内容：

• 5 月 3 日，安装了 System Center Endpoint Protection v4.10.209.0，
• 在 5/4 Microsoft SQL Server 数据层应用程序框架 v14.0.3953.4 和
• 已安装 Microsoft SQL Server 2017 T-SQL 语言服务 v14.0.17230.0。

Answer 1

SSMS 17.8今天（2018 年 6 月 21 日）刚刚发布。也许这会解决你们报告的问题。

Microsoft 文章中概述的说明包括在安装 SSMS 17.8 之前卸载 SSMS 和 VS 2015、验证是否安装了最新版本的 .NET Framework 以及其他几个清单项目的具体步骤。

我按照这些步骤操作，但在使用 SSDT 2015 或更高版本创建的 SSIS 包上添加使用文件系统包源的作业时，SSMS 仍然崩溃。因此，由于这次光荣的失败（感谢 Microsoft！），我将不得不卸载 SQL Server 2017 并安装较低版本。我希望这个帖子上的其他人有更好的运气。

需要注意的一件事：如果您像我一样拥有 Windows Server 2016，则 Microsoft 会说明以下内容：

SSMS 17.X 基于 Visual Studio 2015 独立 shell，该 shell 在 Windows Server 2016 之前发布。如果您在 Windows Server 2016 上遇到 SSMS 的任何问题，请联系支持人员。支持团队确定问题是与 SSMS、Visual Studio 还是与 Windows 兼容性有关。然后，支持团队将问题发送给适当的团队进行进一步调查。