私はこれを一日中頑張っていて、行き詰まっています。今朝、私たちのアジアの同僚から電話がありました。私たちの製品データ管理システム用のSolidWorksアドインがローカルのメインアプリケーションと通信できなかったためです。この問題は、Windowsドメイン内のエンドユーザーのコンピューターに影響します。 SQLサーバーツールボックスのREADPIPEおよびMAKEPIPEユーティリティを使用して、根本的な問題がWindowsパイプ機能であることを突き止めました。
どんな助けでもありがたいです!ありがとうございました。
すべてのケースでそれを理解するのに1.5日必要でした。ドキュメントはこちら。
一部のアプリでは、Windows名前付きパイプを介してプロセス間通信が実装されています(UNIXスタイルのパイプと混同しないでください)。 MSDNドキュメントを参照してください: http://msdn.Microsoft.com/en-us/library/aa365590.aspx
Windowsの名前パイプが機能しない原因はいくつかあります。パイプが問題の原因であることを確認するには、MAKEPIPEおよびREADPIPEツールを使用できます。このKB記事では、テスト手順について説明しています。 http://support.Microsoft.com/kb/68941 Sysinternalsツールのプロセスエクスプローラーは、現在開いているパイプを調べるのにも役立つ場合があります。 「検索->ハンドルまたはDLLを検索...」オプションを使用して、パターン「\ Device\NamedPipe \」を入力します。どのプロセスがどのパイプを開いているかが表示されます。 http://technet.Microsoft.com/en-us/sysinternals/bb896653.aspx
原因1:アプリケーションがパイプファイアウォールによってブロックされている
Windowsでは、アプリケーションが名前付きパイプを使用できないようにすることができます。このファイアウォールは通常有効になっておらず、レジストリを介して構成されます。 MSサポートの記事 http://support.Microsoft.com/kb/92589 をご覧ください。パイプファイアウォールが有効になっていないことを確認するか、許可されているアプリケーションのリストにKeytechとすべてのアドインを追加します。
原因2:ファイルとプリンターの共有サービスが有効になっていません。
名前付きパイプは、ファイルとプリンターの共有も制御するプロセスによって有効になります。このプロセスがWindowsサービスツールを使用して実行されていることを確認します。サービス名は、サービスリストに「サーバー」と表示されます。サービス名はLanmanServerで、EXEはC:\ Windows\system32\svchost.exe -k netsvcsです。
原因3:WindowsファイアウォールがLanmanServerをブロックしている
Windowsファイアウォールは、同じマシン上のプロセス間通信にのみ使用される場合でも、名前付きパイプをブロックできます。特にドメインとローカルのファイアウォールルールは競合を引き起こす可能性があります。 「Windows Firewall Allowed Programs」リストの2つのエントリは、競合を示しています。ほとんどの場合、この問題は「ファイアウォールステータスの確認」ウィンドウを使用して解決できます。このウィンドウに推奨ファイアウォールルールを設定するオプションが表示されている場合、このオプションを使用してパイプのブロックを解除できることがよくあります。ドメインファイアウォールルールと組み合わせると、最初にドメインからPCの参加を解除してから、ファイルとプリンターの共有サービスを許可する必要がある場合があります。