きっとスカイプでしょうね。インストールされている場合は、以下のチェックボックスのチェックを外してください。

高架下のコマンドプロンプトから以下を実行します。

netstat -ab

これを読んでいる人は、システムプロセスを使用しているサードパーティの、マイクロソフト以外のアプリケーションについて話している回答は無視して構いません。

1. Systemプロセスは、すべての現代のWindowsシステムでPID 4としてリストアップされています。これはカーネルモードでのアクセス用です。これは、Apache のようなサードパーティのウェブ製品を除外しています。

2. WinRM (Windows Remote Management) の登場以来、HTTP サービス (%SystemRoot%\system32drivers\http.sys ) は、Windows (Vista 以降 / Server 2008 以降) の標準の一部となっています。

3. Microsoft が開発した他のソフトウェアも、IIS 、SQL Reporting Services 、Microsoft Web Deployment Service http://support.microsoft.com/kb/2597817 ) のような System プロセスの下で、%SystemRoot%system32drivers を使用している場合があります。

4. WinRM 1.0 のデフォルトポートは以下の通りです。
   HTTP = 80 HTTPS = 443 WinRM 2.0 以降のデフォルトポートは以下の通りです。
   HTTP = 5985 HTTPS = 5986 以下のコマンドで確認してください。
   Winrm enumerate winrm/config/listener Winrm get http://schemas.microsoft.com/wbem/wsman/1/config

トラブルシューティングの手順。

探しているポート(この場合は443)のプロセス番号を取得します:

…Windowsのマップされていないドライブから「アクセス拒否」を回避するために。
netstat -aon | find “:443” System プロセスの出力は、以下のようになるはずです。
C:>netstat -ano |find “:443” TCP 0.0.0.0.0.0:443 TCP [:::]:443 [:::]:0 LISTENING 4 最後の列はPID(4)です。

1.プロセス内で何が実行されているかを調べるためにtasklistを実行しても役に立たないことが判明しました。
tasklist /SVC /FI “PID eq 4” tasklist /m /FI “PID eq 4”

1. HTTP サービスのレジストリを探します。HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\services\HTTPParameters\UrlAclInfo どのアプリケーションが動作していて、どのポートを保持しているかを知ることができるURLのリスト(ポート番号付き)があります。
   http:// +:5985/wsman/ –> WinRM https:// +:5986/wsman/ –> WinRM http:// +:80/Reports/ –> SQL Reporting Server http:// +. 80/ReportsServer/ ——> SQL Reporting Server https:// server_fqdn:443/Reports/ —-> SQL Reporting Server https:// server_fqdn:443/ReportsServer/ —-> SQL Reporting Server http:// * . 5358/ –> Web Services Dynamic Discovery (WS-Discovery)

あとは、対応するサービスをシステム上で見つけて停止し、別の netstat -aon | find “:443”コマンドで確認することで、目的のポートが解放されていることを確認することができます。

Windows7のマシンでPID4の「システム」で443番ポートが使用されているという問題がありました。私の場合の解決策は、ネットワーク接続フォルダに存在していた「着信接続」(VPN)を削除することでした。

作成してしまったようで、使用後に削除するのを忘れてしまったようです…。

多くの場合、これはVMwareホストエージェントサービス（VMホスト間の通信に必要）である - vmware-hostd.exe.

svchost.exeが実行されているサブプロセスを確認する良い方法は、Sysinternalsの Process Explorer .

私は、443リクエストをWASサーバにルーティングする際に同様の問題に直面しました。この質問の推奨事項に基づいて、私が行ったことは以下の通りです。

1.昇格した cmd プロンプトから netstat -a -n -o | findstr 443 2. 443でリッスンしているプロセスのPIDを特定

1. プロセスエクスプローラを使用して、PIDからプロセスを識別しました。
2. 私の場合、リスニングしているアプリケーションは vmwarehostd.exe
3. services.mscからVMware Workstationサーバを停止。5.WASサーバで再起動。

そして、443のリクエストは全てハッピーエバーアフターで443になりました。

PS: Windows 8のインストール時に内蔵されていたskypeをアンインストールしていました。私のマシンではルーティングとリモートアクセスサービスは無効になっていました。

サービスによって起動されたプロセスであれば、netstat -abでは何の役にも立ちません。

この場合、管理者コマンドラインでnetstat -ao | find /i "443"を試してみてください。すると、以下のような出力が得られます。

TCP 0.0.0.0:443 your_hostname:0 LISTENING PID

次に、別の管理者コマンドプロンプトでtasklist | find /i "<PID>"と入力します。

tasklist | find /i "2912"

私の場合、PIDは2912で、私のコマンドは次のようになりました。

私の場合は、F5 NetworksのDataManagerで、内部的にTomcat 6を使用してWebページを提供していました。そのアプリをアンインストールするのを忘れていました。私に言わせれば、悪いデザインの決定です。

私の場合、443ポートを使用するのはDTC(Distributed Transaction Coordinator)プロセスでした。特にDTCでWS-ATを起動したところ、443ポートを使用していました。

一般的には、システムプロセス（PID 4）が443/HTTPSポートを使用している場合、それを使用しているIISのWebサイトでなければ、Windowsの内部プロセス（私の場合はDTCですが、別のプロセスでもよいと思います）だと理解しています。

netstat -ao | find ":443"を使用して、443番ポートがシステムプロセスであるPID 4によって使用されていることがわかりました。これはWindows Server 2012で2回ほど発生したのですが、以下のいずれかの原因で発生していました。

1.IIS が起動していて、サービスの中に「World Wide Web Publishing Service」と表示されていたので、これを停止しました。 2. 作業フォルダ機能がインストールされていたので、アンインストールした。

これは万人向けの解決策ではないかもしれませんが、一部の人には役立つかもしれません。

Windows 8（おそらくWindows 7でも同様）でVPN機能を使用すると443番ポートが使用されていることがわかりました。

さらに、PMB.exe（Pando Media Booster）で再びポートが閉じてしまいました。

私の場合、Windows Server 2016のアップデート後、Apache 443が通常のイベントが羅列された状態で起動できませんでした。

犯人は「Windows Sync Share」サービス（SyncShareSvc）だとわかりました。無効にして、Apacheを起動することができました。

私の場合は、ポート 80 でリスンしている McAfee EPO エージェントが原因でした。これを変更してもらうために、いくつかの苦しい手続きを踏まなければなりませんでした。 https://kc.mcafee.com/corporate/index?page=content&id=KB67605

私のWindows Server 2019では、このPSを実行することで解決しました。

Stop-Service -Name KPSSVC

ネットワークサービス権限でプロセス4(SYSTEMプロセス)として実行しました。

netstat -ab

を実行しても解決しませんでした。Can not obtain ownership information」と表示された。

サービスを停止した後、netstat -aon | findstr “:443 "を実行してもエントリが表示されなくなった。リテラルでサービスを1つ1つ停止してみて判明。

KDC Proxy Serverサービス(KPS) - KDC Proxy Serverサービスはエッジサーバ上で動作し、企業ネットワーク上のドメインコントローラにKerberosプロトコルのメッセージをプロキシします。

Wiresharkで詳細がわかります。 http://www.wireshark.org/ またはTCPモニタ。 http://www.itsamples.com/tcp-monitor.html

これで解決。

ある種の仮想LANドライバ(OpenVMやVMwareなど)を使用している場合、ポートを他の何かに渡す前に、そのポートを「解放」することを確認してください。

ちょっとしたヒントです。)

VMwareのアップデートをインストールしようとしたときに同じ問題が発生しました。Skypeで原因を突き止めました。新しいクライアントのデフォルトは443です。