Jakie są przyczyny niepowodzenia lokalnych potoków nazwanych systemu Windows?

Ciężko nad tym pracowałem cały dzień i utknąłem. Dziś rano zadzwonili do mnie koledzy z Azji, ponieważ dodatek SolidWorks do naszego systemu zarządzania danymi produktu nie mógł komunikować się z lokalną główną aplikacją. Problem dotyczy komputerów użytkowników końcowych w domenie Windows. Użyliśmy narzędzi READPIPE i MAKEPIPE z przybornika serwera SQL, aby dowiedzieć się, że podstawowym problemem była funkcja potoku Windows.

• Narzędzie MAKEPIPE tworzy potok i czeka na klienta. Plik READPIPE zwraca: „Nie można otworzyć rury. Status 53.” Według strony http://support.microsoft.com/kb/110905 oznacza to, że nie znaleziono nazwy sieci. Na moim lokalnym komputerze potoki bez problemu wysyłają „witaj” z READPIPE do MAKEPIPE.
• Proces serwera, który umożliwia nazwane potoki, jest uruchomiony.
• Ustawienia w HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Lanmanserver \ Parameters wyglądają dobrze. Brak ustawień zapory ogniowej.
• Problem dotyczy niektórych użytkowników, ale nie wszystkich. Nie wprowadziliśmy zmian w grupach domen, z wyjątkiem niektórych grup udziałów sieciowych.
• Zalogowałem się jako administrator i nadal potoki nie będą działać.

Każda pomoc jest mile widziana! Dziękuję Ci.

Potrzebowałem 1,5 dnia, aby to rozgryźć dla każdego przypadku. Tutaj do dokumentacji.

Objawy

• Przeciągnij i upuść w aplikacjach nie działa.
• Komunikacja międzyprocesowa np. Między aplikacją główną a dodatkami nie działa.

Przyczyny / tło

W przypadku niektórych aplikacji zaimplementowano komunikację międzyprocesową za pośrednictwem nazwanych potoków systemu Windows (nie należy mylić z potokami w stylu UNIX). Zobacz dokumentację MSDN: http://msdn.microsoft.com/en-us/library/aa365590.aspx

Mogą istnieć różne przyczyny niedziałania potoków nazw systemu Windows. Aby sprawdzić, czy rury są przyczyną problemu, można użyć narzędzi MAKEPIPE i READPIPE. W tym artykule bazy wiedzy opisano procedurę testowania: http://support.microsoft.com/kb/68941 Eksplorator procesów narzędzia Sysinternals może być również przydatny do sprawdzenia, które rury są obecnie otwarte. Użyj opcji „Znajdź -> Znajdź uchwyt lub DLL ...” i wprowadź wzór „\ Device \ NamedPipe \”. Pokaże Ci, które procesy mają otwarte rury. http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Rozwiązywanie problemów

Przyczyna 1: Aplikacja jest blokowana przez zaporę Pipes

System Windows może blokować aplikacjom używanie nazwanych potoków. Ta zapora zwykle nie jest włączona i jest konfigurowana przez rejestr. Zobacz artykuł pomocy technicznej MS tutaj: http://support.microsoft.com/kb/925890 . Sprawdź, czy zapora rurowa nie jest włączona lub dodaj Keytech i wszystkie dodatki do listy dozwolonych aplikacji.

Przyczyna 2: Usługa udostępniania plików i drukarek nie jest włączona.

Nazwane potoki są włączane przez proces, który kontroluje także udostępnianie plików i drukarek. Sprawdź, czy ten proces jest uruchomiony za pomocą narzędzia Windows Services. Nazwa usługi jest wyświetlana na liście usług jako „Serwer”. Nazwa usługi to LanmanServer, a plik EXE to C: \ Windows \ system32 \ svchost.exe -k netsvcs

Przyczyna 3: Zapora systemu Windows blokuje LanmanServer

Zapora systemu Windows może blokować nazwane potoki, nawet jeśli są one używane tylko do komunikacji między procesami na tym samym komputerze. W szczególności konflikt może powodować domeny i lokalne reguły zapory. Dwa wpisy na liście „Programy dozwolone w Zaporze systemu Windows” wskazują na konflikt. W większości przypadków ten problem można rozwiązać za pomocą okna „Sprawdź stan zapory”. Jeśli to okno pokazuje opcję ustawiania zalecanych reguł zapory, potoki można często odblokować za pomocą tej opcji. W połączeniu z regułami zapory domeny czasami konieczne jest odłączenie komputera od domeny, a następnie zezwolenie na usługę udostępniania plików i drukarek.