0x800706baエラーの原因と対処法｜WindowsでRPCサーバーを利用できないときの解決策
Windowsで「RPCサーバーを利用できません」「The RPC server is unavailable」と表示され、操作が止まることがあります。エラーコード0x800706baは、RPC（Remote Procedure Call）を使った通信を相手先と確立できないときに表示される代表的なコードです。
原因は、RPCサービスそのものの停止だけではありません。対象PCの電源やネットワーク、名前解決、TCP 135やRPC動的ポートを遮断するファイアウォール、WMI・DCOMなどアプリ固有の権限が関係する場合もあります。この記事では、影響範囲を確認してから、原因を安全に切り分ける順番を解説します。
先に結論：まず接続先のPC名と発生した操作を確認し、対象PCの稼働状態、RPC関連サービス、TCP 135への到達性、ファイアウォールのRPC動的ポート許可を順に調べます。Windows Defender Firewallを全面的に無効化したり、レジストリを勘で変更したりするのは避けてください。
0x800706baエラーの意味
0x800706baは、Windowsのエラー名ではRPC_S_SERVER_UNAVAILABLEに相当し、要求したRPCサーバーへ接続できないことを表します。ここでいう「サーバー」は、必ずしもインターネット上のサーバーではありません。同じPC上の別プロセス、家庭内LANの別PC、社内サーバー、ドメインコントローラーなども含まれます。
RPCは、クライアント側のアプリが別のプロセスやコンピューター上のサービスを呼び出すための仕組みです。Windowsの管理ツール、WMI、Active Directory、印刷、証明書登録、リモート管理など、さまざまな機能がRPCを利用します。そのため、同じ0x800706baでも、どの操作で出たかによって対処が変わります。
Microsoftの説明では、クライアントはまずRPC Endpoint Mapperへ接続し、その後、サービスに割り当てられた動的ポートへ接続します。TCP 135に到達できても、後半の動的ポートが遮断されていればRPC処理は失敗します。
0x800706baが出る主な原因
対象PCまたは対象サービスが停止している
リモート接続先のPCが電源オフ、スリープ、ネットワーク切断の状態だと、RPCサーバーを利用できません。対象アプリが使うサービスだけが停止しているケースもあります。再起動直後やWindows Updateの後に発生した場合は、サービスの起動状態とイベントログを確認します。
ホスト名を正しく解決できない
接続先をコンピューター名で指定している場合、DNS、VPN、社内ネットワークの経路が原因になることがあります。名前から誤ったIPアドレスを返している、VPN接続が切れている、別のネットワークプロファイルに接続している、といった状態でもRPCは失敗します。
TCP 135またはRPC動的ポートが遮断されている
RPC Endpoint Mapperが使うTCP 135と、続けて割り当てられる動的ポートのどちらかが、Windows Defender Firewallやネットワーク機器で遮断されている可能性があります。TCP 135だけを許可しても、サービスが使う動的ポートへ到達できなければ解決しません。
WMI・DCOM・アプリ固有の権限やポリシーが合っていない
WMI接続や証明書登録などでは、通信経路だけでなく、利用するアカウントの権限、DCOMのアクセス許可、グループポリシー、サービス固有の設定も関係します。通信が届いていても認証やアクセス許可の段階で失敗すると、同じコードが表示される場合があります。
最初に行う切り分け
1. エラーが出た操作と接続先を記録する
まず、次の項目をメモします。
- エラーが出たアプリや管理ツール
- 操作対象が自分のPCか、別のPC・サーバーか
- 接続先のコンピューター名、可能ならIPアドレス
- 発生したユーザーだけの問題か、複数PC・複数ユーザーに共通する問題か
- 直前に行った更新、VPN接続、ファイアウォールやポリシーの変更
1台のPCだけで発生するなら、そのPCのサービスや設定を優先します。複数のクライアントから同じ接続先にアクセスできないなら、接続先のファイアウォール、ネットワーク機器、RPCを利用するサービスを優先して調べます。
2. 接続先の名前解決とTCP 135を確認する
管理者権限が不要な範囲で、接続元のPowerShellから次のコマンドを実行します。<対象PC名>は実際のコンピューター名に置き換えてください。
Resolve-DnsName <対象PC名>
Test-NetConnection <対象PC名> -Port 135Resolve-DnsNameで想定したアドレスが返るかを確認し、Test-NetConnectionのTcpTestSucceededを確認します。TCP 135への接続が失敗するなら、対象PCの稼働状態、名前解決、VPN、経路、ファイアウォールを先に直します。
ただし、TCP 135のテストが成功してもRPC全体の疎通が保証されたわけではありません。Endpoint Mapperの後に使われる動的ポートや、WMI・DCOMなどサービス固有の権限が残るためです。
3. 対象PCのRPC関連サービスを確認する
対象PCにログインできる場合は、services.mscを開き、「Remote Procedure Call (RPC)」や「RPC Endpoint Mapper」の状態を確認します。PowerShellでは、次のようにサービス情報を確認できます。
Get-Service RpcSs, RpcEptMapperRPCは多くのWindows機能が依存する基盤サービスです。停止している場合でも、依存関係やイベントログを確認せずにサービスのスタートアップ設定を変更しないでください。サービスが起動できない、すぐ停止する、依存サービスでエラーが出る場合は、対象のイベントログを保存してからWindowsの修復や管理者・サポート窓口への相談を検討します。
0x800706baの対処法
対象PCの電源・ネットワーク・VPNを確認する
リモートPCが起動しているか、ネットワークケーブルや無線接続に問題がないかを確認します。社内サーバーへVPN経由で接続している場合は、VPNが接続済みでも社内DNSや対象サブネットへの経路が有効とは限りません。接続先をIPアドレスで指定したテストと、コンピューター名で指定したテストを分けると、名前解決の問題を見つけやすくなります。
Windows Defender FirewallのRPCルールを確認する
接続先のPCでwf.mscを開き、Windows Defender Firewall with Advanced Securityの受信規則を確認します。RPCを利用する機能では、少なくとも次の2段階を意識します。
- RPC Endpoint MapperへのTCP 135の通信
- Endpoint Mapperが案内したRPC動的ポートへの通信
Microsoftのファイアウォール手順でも、RPC Endpoint Mapper用の規則と、RPC対応サービスの動的ポート用の規則を分けて作成します。規則が無効になっていないか、接続先のネットワークプロファイル（ドメイン、プライベート、パブリック）が想定と一致しているか、接続元のIPアドレスがスコープ外になっていないかを確認してください。
確認のためにファイアウォールを全面的に無効化する方法は、常用しないでください。検証が必要な場合も、管理者の承認、短時間の実施、通信元・通信先の限定、実施後の再有効化を必ず行います。社内のネットワークファイアウォールを通過する構成では、Windows側だけを変更しても直らないため、ネットワーク管理者にTCP 135と動的ポートの許可範囲を確認します。
ネットワークプロファイルと許可範囲を見直す
同じPCでも、ネットワークが「パブリック」に分類されると、プライベートやドメイン向けに作られた受信規則が適用されないことがあります。利用環境に合うプロファイルだけで規則を有効にし、可能なら接続元のサブネットや管理対象のIPアドレスに範囲を限定します。インターネット全体からRPCを受け付ける設定は避けてください。
利用元に合わせてWMI・DCOM・サービス権限を確認する
WMI、イベントビューアーのリモート接続、証明書登録、印刷、ドメイン管理など、どの機能がRPCを呼び出しているかを特定します。各機能で必要なファイアウォール規則やアカウント権限が異なるため、RPCのエラーだけを見てDCOMの設定やグループポリシーを一括変更するのは危険です。
WMIで発生している場合は、接続先のWindows Firewallログ、WMI関連のイベント、RPC動的ポート、DCOMや認証に関する設定を確認します。証明書登録やActive Directoryなど特定製品の処理なら、その役割専用のMicrosoft手順に合わせて確認してください。
変更後は対象アプリと接続を再確認する
ファイアウォール規則やVPNを修正したら、対象アプリをいったん終了して再接続します。サービス設定や動的ポート範囲を変更した場合は、必要な再起動の有無を手順書で確認します。再発する場合は、エラーが出た時刻、接続元・接続先、変更した規則、イベントログの内容をまとめると、管理者やサポートが調査しやすくなります。
直らないときの詳細確認
ファイアウォールのブロックログとイベントログを見る
Windows Firewallによる遮断が疑われる場合は、イベントビューアーの「アプリケーションとサービス ログ」から、Windows Firewall with Advanced Securityのログを確認します。ブロックされた通信の時刻、送信元・送信先IP、ポート番号が分かれば、TCP 135で止まっているのか、動的ポートで止まっているのかを切り分けられます。
同じ時刻の「Windowsログ > システム」や、対象サービス固有のログも確認します。接続先が停止した、サービスが異常終了した、認証に失敗したなど、RPCより前後の原因が記録されていることがあります。
RPC動的ポート範囲を確認する
環境によっては、ファイアウォールで許可するRPC動的ポートの範囲を確認する必要があります。MicrosoftのWMIトラブルシューティング手順では、次のコマンドでTCP・UDPの動的ポート範囲を確認しています。
netsh int ipv4 show dynamicport tcp
netsh int ipv4 show dynamicport udp
netsh int ipv6 show dynamicport tcp
netsh int ipv6 show dynamicport udpここで表示された範囲を、すぐに広範囲で開放するという意味ではありません。必要な通信元・通信先と利用サービスを確認し、ネットワーク管理者と安全な許可範囲を決めます。
レジストリ変更は最後にする
RPCの動的ポートを固定範囲に制限する方法はありますが、対象サービス、他のRPC利用サービス、同時接続数、ファイアウォール設計を理解したうえで行う管理者向けの設定です。Microsoftの資料に出てくるポート範囲は仕組みを説明する例であり、すべての環境にそのまま適用する推奨値ではありません。
レジストリを変更する場合は、事前にバックアップと変更手順・復旧手順を用意し、変更後に必要な再起動と疎通確認を行います。家庭用PCで一時的に出た0x800706baに対して、根拠なくHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc以下を追加するのは避けてください。
まとめ
0x800706baは「RPCサーバーが必ず停止している」という意味ではなく、RPC通信を確立できない状態を示します。次の順番で確認すると、原因を絞り込みやすくなります。
- エラーが出たアプリ、接続先、発生範囲を確認する
- 対象PCの稼働状態、名前解決、VPN、TCP 135への到達性を確認する
- RPC関連サービス、Windows Firewallのプロファイルと受信規則を確認する
- TCP 135だけでなく、RPC動的ポートとネットワーク機器の許可範囲を確認する
- WMI・DCOM・証明書・印刷など、実際に使っている機能固有の権限とログを確認する
まずはサービスと通信経路を確認し、それでも直らない場合にログと動的ポートを調べるのが安全です。ファイアウォールの全面無効化やレジストリの無計画な変更ではなく、必要な通信だけを対象に修正してください。
コメント