关闭ArcMap后,ArcMap.exe进程是否保持打开状态?[关闭]


23

我意识到这是几个月前发生的,当我关闭另一个实例后,无法在ArcMap实例中更改表结构时。例如,当我在ArcMap中将某些字段删除或添加到要素类时,保存并关闭文档并打开ArcCatalog并尝试删除该特定要素类时,出现“删除失败:删除所选对象失败”错误。当打开包含我要删除的图层的ArcMap实例时,通常会发生这种情况,因此解决方法是启动Windows任务管理器并杀死由于某些原因仍打开的ArcMap.exe进程。

还有其他人遇到这个问题吗?

现在正在运行SP3,此问题尚未解决。

在此处输入图片说明


我在可比较的机器上运行了非常类似的设置,但那里没有此问题。


4
是!请在ESRI论坛上查看我的论坛帖子。我正在尝试复制它(似乎是随机的……),以便使用ESRI打开票证。
SaultDon

您是否已加载任何第三方扩展?我想知道IExtension.Shutdown中的异常是否可以解释这一点。
Kirk Kuykendall,

@kirk我什么都没有,也从未在v10的此安装中安装任何东西。这甚至是Windows7的新安装。与您类似,此问题自SP1之前就一直存在。
2011年

2
您正在运行将近100个进程,可能确实是任何事情,但我对病毒扫描程序,备份软件和搜索索引服务最为怀疑。
blah238

@Kirk-此特定设置没有扩展名,但是上班时我会仔细检查。我有一些自己的附加工具。我在另一台Windows 7计算机上具有类似的设置,具有相同的加载项,并且在那里没有问题。
Jakub Sisak GeoGraphics

Answers:


18

不是您的错,您也无能为力。但是,如果您对原因感到好奇,那么将发生一个COM循环引用(最有可能是监听某些事件源的对象,例如Editor),而应用程序试图退出时则无法,因为某些对象正在保留该引用。彼此还活着。这可以来自您已安装的扩展,甚至可以来自ESRI代码本身。这曾经一直发生,并且可能仅在某些条件下才会表现出来,例如某些命令在工具栏中可见。

摘自有关COM概念的旧ArcObjects教程

当应用程序退出时,它将释放对命令的引用。如果该命令还用作事件接收器,则应用程序将保留对该命令的另一个引用,除非该命令与源断开连接,否则该引用将无法释放。由于命令不知道除自身的析构函数之外还可以断开连接的点,因此这会导致循环引用,从而应用程序无法在不破坏命令的情况下退出,并且命令的析构函数永远不会被调用,因为应用程序拥有对命令的引用。这将导致应用程序在退出时挂起。

如果您更好奇,请删除(或备份)Normal.mxt,这将清除所有自定义项,并查看此问题是否仍然存在。


3
+1很好的解释。让我想知道是否关闭除一个以外的所有命令栏,然后保存并退出并尝试重现该问题。我不认为ICommand.OnCreate会在工具栏可见之前被调用。如果逐渐打开工具栏并重复测试,则可以缩小可疑命令的范围。
Kirk Kuykendall

很好的解释。谢谢。@Kirk-我确实忘记了(ArcBruTile)的第3方工具,因此我将其删除。我的加载项确实确实进行了一些事件侦听,所以我想知道我的工具栏是否可能是问题的根源。奇怪的是,我在另一台计算机上拥有相同的工具,并且加载了相同的默认工具栏集,而我在那里没有这个问题。我将尝试从重新创建Normal.mxt开始,这是一个很好的建议。
Jakub Sisak GeoGraphics

同样,有时当仅可见的动作不一定足以引起循环引用时,可能需要发生一些事件以使该条件显现出来。例如,该命令是可见的,并且一切都很好,等待“ StartEditing”事件发生。一旦触发,它决定开始获取对其他事物的引用-并在那里设置确实导致循环条件的其他引用。由于不确定的垃圾回收,这是VB扩展的经典问题,甚至还有.NET命令的经典问题
Ragi Yaser Burhum 2011年

2

谢谢@Kirk和@Ragi解决了这个问题!这是我监视任务管理器过程时所做的事情:

  1. 备份并删除Normal.mxt
  2. 启动新的ArcMap文档(以默认配置打开ArcMap)
  3. 已关闭ArcMap(进程已按预期关闭)
  4. 添加的Toobars:3D Analyst,高级编辑,数据框工具,绘制,编辑顶点,编辑器,地理参考,标签,布局,捕捉
  5. 排列好的工具栏
  6. 已关闭ArcMap(进程已按预期关闭)
  7. 开始新的ArcMap文档
  8. 添加了我自己的自定义工具栏和加载项
  9. 已关闭ArcMap(进程已按预期关闭)
  10. 启动现有的ArcMap文档
  11. 在我的工具栏以及几个自定义工具上使用了自定义开始和停止编辑
  12. 已关闭ArcMap(进程已按预期关闭)

我还删除和删除了ArcBruTile

ArcMap流程现在已按预期关闭


2
讲得太早了。问题又回来了。
Jakub Sisak GeoGraphics

不幸的是,ESRI支持一直在复制并粘贴上面的答案作为解决方案,当它似乎不起作用时:/
MaryBeth

@Jakub您是否找到解决此问题的方法?我正在创建一个插件,最近注意到退出后正在运行多个ArcMap进程。
Barbarossa

似乎已经达成共识,即该进程是由第三方添加/扩展程序打开的并且未正确关闭。我构建了自己的插件,我可能已经检查了所有代码,以确保所有对象都已释放,或者更有可能的是,ESRI已在源头修复了该问题,因为该问题不再在10.3中发生,并且我相信在10.2。如果仍然发生这种情况,请卸载和/或删除所有第3方插件,然后查看问题是否仍然存在。如果不停转弯,则逐一添加以找出罪魁祸首。希望这可以帮助。
Jakub Sisak GeoGraphics 2015年

2

并非试图使这篇文章从死里逃生,而是在Citrix服务器上使用此问题与ESRI支持一起工作(用户崩溃或注销时,arcgiscachemanager.exe不会在20-30分钟后关闭,甚至根本不会关闭),用户无法重新登录ArcMap,然后他们必须依靠2位服务器管理员才能登录到服务器并手动释放他们),ESRI正在从此页面复制并粘贴解决方案,但此方法无效。至少在Citrix环境中工作时没有。

对于Citrix,我们发现创建两个注册表项(一个用于杀死挂起的进程,一个用于将设置恢复到原始状态)可以解决此问题。

对于非Citrix,我们只是想创建一个脚本来终止进程的想法,但是由于不在Citrix中时,我们已经在服务器上了,因此我们决定没有必要。

希望这可以帮助。

-------从升级的支持通知单中复制的数据-------- Citrix具有注册表项设置,可帮助管理在后台生成辅助进程的应用程序。您有很多症状,应使此解决方案成为可能。浏览以下Citrix知识文章:

从已发布的应用程序正常注销使会话处于活动状态:http : //support.citrix.com/article/CTX891671

从Windows Server 2003升级到Windows Server 2008时,用户在XenApp环境中注销后的活动会话:http : //support.citrix.com/article/CTX134956

XenApp 6.5 AppCenter控制台显示应用程序状态应用程序未运行:http : //support.citrix.com/article/CTX133328

在这些文章中,它讨论了已发布的应用程序如何导致会话无法关闭或用户未正确注销。在这些情况下,必须由管理员重置或退出会话,或者通过从仍在运行的服务器终止进程来重置/退出会话。在Citrix中,您发布的主要应用程序是ArcMap。退出应用程序时(或崩溃时)仅关闭该exe文件。结果,在打开应用程序时产生的与该应用程序相关的所有exe都不会在Citrix中完全关闭,从而导致此状态。因此,当ArcGISCacheMgr.exe需要很长时间才能执行或应用程序崩溃时,最终用户将无法启动新的会话。

文章讨论了如何将这些辅助进程添加到注册表项,以在关闭主应用程序时自动将其关闭。您可以探索的另一个选择是注销脚本,以检查进程并终止它们(如果存在)。


2

创建一个.bat文件并将其粘贴并保存到桌面。

 taskkill /IM ArcGisCacheMgr.exe /f
 taskkill /IM ArcGisConnection.exe /f
 "C:\Program Files (x86)\ArcGIS\Desktop10.1\bin\ArcMap.exe"

4
解释这些命令(及其选项)的作用将有助于技术人员了解您的解决方案。
whuber

1

SysInternals Suite中的PsKill(我认为这是一个几乎不可或缺的工具包)可以链接到快捷方式,并可以随意触发以清理挂起的进程。这样做很丑陋,因为它无助于解决原始问题,但确实可以使人们快速而有效地进行下去。

pskill -t arcmap.exe

最近,我每周几次获得不可见的arcmap.exe进程,以前没有那么频繁,但是它已经发生了一段时间。我通常使用并发许可。当我有多个活动的Arcmap会话时,这种情况似乎更经常发生。我们在64位Win7上使用Sophos防病毒软件。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.