dcom服务器进程 服务主机：DCOM服务器进程启动器占cpu

其实dcom服务器进程的问题并不复杂，但是又很多的朋友都不太了解服务主机:DCOM服务器进程启动器占cpu，因此呢，今天小编就来为大家分享dcom服务器进程的一些知识，希望可以帮助到大家，下面我们一起来看看这个问题的分析吧！

服务主机:DCOM服务器进程启动器占cpu

如下的解决方法请参考：

打开任务管理器，在电脑下方任务栏上右键----任务管理器

任务管理器，点击“CPU”显示最高的那个就是“服务主机本地系统（网络受限）”

解决办法是关闭Superfetch这个服务

在我的电脑图标或者“这台电脑”图标上右键----管理----服务和应用程序----服务

服务里面找到Superfetch这个服务，右键----停止，重新打开任务管理器，可以马上看到效果，或者说电脑马上就没那么卡了，搞定

Dcom服务作用

dcom服务概要--

DCOM实际上是一项协议，它能让软件组件以一种可靠、安全和高效的方式通过网络进行直接通讯。DCOM以前称为“网络 OLE”，其设计使它能用在多种网络传输（包括 HTTP等 Internet协议）上。DCOM以开放软件基金会的 DCE-RPC规范为基础，并可以通过组件对象模型(COM)而用于 Java语言小程序和 ActiveX®组件。

Terminal Server 4.0中的 DCOM功能是常规 Windows NT Server 4.0 DCOM功能的一个子集。基于这一点，针对常规 Windows NT Server 4.0环境编写并能在其上正常运行的一些应用程序，在终端服务器上可能无法正常运行。本文的目的就是说明那些使用 DCOM功能的应用程序会出现什么样的行为。

以下 DCOM功能可以在终端服务器上获得全面支持：

客户端行为（作为终端服务器的任一用户运行并通过 DCOM调用其它机器的进程）没有变化。

如果没有直接或间接涉及 COM激活过程（CoGetClassObject、CoCreateInstanceEx、由于远程调用而启动的进程等），则服务器端的行为也没有变化。例如，如果指向终端服务器机器上 COM对象的接口指针被调整并传递给另一机器上的客户代码，则服务器端行为就不涉及激活过程。这种行为的发生通常是作为 DCOM方法调用的输出参数，但也可能存在其它方式。那种情况下，对终端服务器（现在已作为 DCOM服务器）的回调将照常进行（包括通常的安全限制）。一个间接激活的例子是，对一个解析到终端服务器机器并导致尝试在该机器上发生直接激活的文件标记的绑定。

DCOM激活模式和终端服务器

在作为远程客户的服务器运行时，终端服务器系统在所支持的 DCOM激活/进程启动模式方面会有所限制。对于任一给定的 ClassID或 AppID，Windows NT的 DCOM通常支持四种激活/启动模式。

作为激活方运行（默认）：在终端服务器中，本地进程由客户会话启动。

作为指定/命名用户运行：在终端服务器中，本地进程始终由会话 0（控制台）启动。

作为 Win32和 Windows NT服务运行：在终端服务器中，服务由会话 0（控制台）启动。

作为交互用户运行：不能用在终端服务器中。

对于终端服务器，只有模式 1（“作为激活方运行“）才受完全支持。模式 2和 3（“作为指定/命名用户运行”和“作为 Win32和 Windows NT服务运行”）在终端服务器系统上运行时会出现不同的行为，因此 Microsoft不推荐或支持这样做。第四种模式（“作为交互用户运行”），在终端服务器上根本不能运行。

DCOM与 Windows 2000终端服务

Microsoft的目标是确保上述问题在 Windows 2000中能够解决。以下内容是对 Microsoft Windows® 2000终端服务下激活模式及其工作机制的简要

作为激活方运行：

本地激活：

服务器在激活方所属的同一会话中被激活。这种行为在无论终端服务是否启用的情况下都完全相同。

远程激活：

启用终端服务后的激活规则与不启用时一样。然而，进程将在会话 ID为 0的窗口站中启动，而不是在用户对应的会话中启动。这是为了保护远程调用的激活行为。为了说明这一行为方式的原因，不妨假设由对应于 Windows 2000 Server（已启用终端服务）上用户的会话启动激活过程的情况。如果用户注销，所有的窗口站及其进程就被杀死。如果用户是从服务器上的多个客户登录的，而又决定从一台客户机上退出，则用户其它会话的客户进程将无法看到它们的激活过程。因此，其它会话将失败。基于这一原因，所有进程都将在会话 0的窗口站中启动。因为会话 0永远不会被删除，远程激活过程就能够继续正常进行。

作为命名/指定用户运行：

应用程序通过注册表中的 AppID被配置为作为指定用户运行。本地和远程激活的行为相同。

当启用了终端服务时，进程将在会话 0的一个新窗口站中启动。在有多个用户使用服务器的情况下，后续请求将获得已有的同一个类对象。呼叫方的 SID或 LUID对此没有影响。在单个用户使用服务器的情况下，新的激活请求始终获得一个新的窗口站。即使同一用户登录到交互式桌面，激活过程也不会共享交互窗口站。

作为 Win32和 Windows NT服务运行：

应用程序通过 AppID集被配置为作为服务运行进程。

当启用了终端服务后，服务从本质上讲仍是全局的，不会在某一特定会话中启动。根据服务配置不同，它们要么在会话 0的服务桌面上启动，要么在会话 0的交互桌面上启动。

作为交互用户运行：

应用程序被配置为在交互用户的安全环境下运行。

如前所述，Windows NT Server 4.0，Terminal Server Edition不支持这类服务器的远程激活，它只支持会话到会话的本地激活。在启用终端服务的状态下作为交互用户启动进程有两种方式，正处于研究之中。一种在当前会话之外的另一会话中激活进程的方式是使用会话“标志”。另一种可能的方式是使用呼叫方的安全凭据启动进程。Windows 2000正式推出时会提供更详细的信息

关于dcom服务器进程和服务主机:DCOM服务器进程启动器占cpu的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。