☰

이상한 인쇄 문제: Windows 공유 프린터는 호스트 이름을 통해 액세스/표시되지만 IP 주소를 통해서는 볼 수 없습니다.

tag-icon • tag-icon windows printing
이상한 인쇄 문제: Windows 공유 프린터는 호스트 이름을 통해 액세스/표시되지만 IP 주소를 통해서는 볼 수 없습니다.

약 8~10개월 전부터 우리는 이상한 프린터 문제에 직면해 왔으며 이번 달에는 회사 대부분이 관련된 엄청난 양의 오류로 정점에 달했고 이로 인해 핵심 문제를 식별할 수 있었습니다. 일부 컴퓨터(~7- 8%) 때때로 재부팅 후 인쇄 스풀러에 문제가 발생하여 프린터가 IP 주소를 통해서만 광고/사용 가능하지 않고 호스트 이름을 통해서만 사용 가능하게 됩니다.

특히 이 문제는 세 가지 방식으로 나타납니다.

  • Linux 서버에서 인쇄를 보낼 때 서버에 오류가 발생하고 이벤트 로그에 "자동 LPD(라인 프린터 데몬) 서비스가 \%WindowsIP%%PrinterName% 프린터에 대한 %LINUXSERVERIP%의 인쇄 작업을 거부했습니다."라는 오류가 표시됩니다. 지정한 프린터가 이 컴퓨터에 없기 때문입니다."

  • Windows 탐색기에서 \%WindowsIP%\를 사용하여 Windows 컴퓨터로 이동하여 Windows 탐색기에서 프린터를 매핑하려고 하면 프린터가 표시되지만 추가하려고 하면 "작업을 완료할 수 없습니다(오류 0x00000709)."라는 오류가 발생합니다. 이는 일반적으로 KBKB5006670과 관련되어 있지만 우리 컴퓨터에 설치되어 있지 않으며 앞서 언급한 오류의 첫 번째 인스턴스는 2021년 12월/2022년 1월이므로 해당 패치가 출시되기 훨씬 전입니다.

  • powershell 명령 Get-Printer -Computername %WindowsIP%를 실행할 때. 명령이 컴퓨터의 호스트 이름으로 실행되면 결과는 정확합니다(공유 프린터 목록). 컴퓨터의 IP 주소로 실행하면 다음 오류가 발생합니다.

      + CategoryInfo          : NotSpecified: (MSFT_Printer:ROOT/StandardCimv2/MSFT_Printer) [Get-Printer], CimException
  + FullyQualifiedErrorId : HRESULT 0x8007007b,Get-Printer

그리고 가장 짜증나는 점은 스풀러 서비스를 다시 시작하면 다음 재부팅 때까지 문제가 완전히 사라진다는 것입니다...

Google에 대한 연구는 답이 없는 단 하나의 메시지를 제외하고는 큰 성공을 거두지 못했습니다.https://hardforum.com/threads/weird-network-printing-problem.1635293/

모든 것에 대한 XKCD가 있지 않습니까?https://xkcd.com/979/

Procmon, Wireshark, Process Explorer, WinDbg 및 xbootmgr을 사용하여 추가 분석을 수행하여 다음과 같은 결과를 얻었습니다.

  • 프로크몬:

    • 다른 컴퓨터에서 Get-Printer %WindowsIP%를 실행하는 동안 spoolsv.exe를 분석한 결과 네트워크 통신 외에는 다른 작업이 표시되지 않습니다.
    • Windows 탐색기를 통해 공유 프린터를 추가하는 동안 spoolsv.exe를 분석하면 "NAME NOT FOUND"라는 결과와 함께 HKU%SIDOFREMOTEACCOUNT% 및 HKU.DEFAULT\Printers\Connections,,%WINDOWSIP%,%PRINTERNAME%에 대한 일부 RegQueryKey와 네트워크 연결이 표시됩니다. 하지만 다른 건 없어
    • 부팅 중 활성화 부팅 로깅을 통한 spoolsv.exe 분석 시도는 성공했지만 해당 옵션을 활성화한 상태에서 부팅할 때 나타나지 않는 문제로 인해 쓸모가 없었습니다.
    • spoolsv.exe에서 스택을 추적하기 위해 스택 요약 기능을 통해 추가 분석이 시도되었지만 작동 중인 procmon 덤프와 작동하지 않는 procmon 덤프 사이에서 공통적으로 나타나는 스레드에서 유일하게 눈에 띄는 차이점은 EatAuthInfoFromPacket이라는 추가 분기가 있다는 점이었습니다. 작업 서비스 덤프.

  • 와이어샤크:

    • 원격 시스템에서 Get-Printer를 실행하는 동안 트래픽 흐름을 피상적으로 분석하면 IREMOTEWINSPOOL 프로토콜을 사용한 Winspool_AsyncEnumPrinters 요청 및 Winspool_AsyncEnumPrinters 응답이 표시되지만 추가 정보가 없고 스텁 데이터가 암호화되어 표시되므로 추가 정보를 얻을 수 없습니다.

  • 프로세스 탐색기

    • spoolsv.exe 프로세스와 해당 스레드 및 스택에 대해 피상적인 분석이 수행되었으며 유일하게 흥미로운 점은 spoolsv.exe 프로세스의 문자열에 손상되었을 때 \machinehostname 및 \machinehostname.domain.com이 있었고 손상되었을 때는 아무 것도 없었다는 것입니다. 그렇지 않았습니다. 하지만 Windows 내부에 대한 지식이 완전히 이해하기에는 부족하다는 점을 인정해야 합니다. 그래도 OpenAI가 설명을 도와주었습니다!

  • WinDbg

    • 디버거가 spoolsv.exe 프로세스에 연결되었으며 원격 시스템의 Get-Printer와 Windows 탐색기를 통해 프린터 매핑을 모두 사용하여 테스트가 완료되었지만 두 경우 모두 실행 중에 디버그 메시지가 표시되지 않았습니다. 또한 Process Explorer에서 프로세스 덤프를 생성하고 이를 WindDbg에 제공하여 !analyze 명령을 실행했지만 중단점만 반환하고 실제 오류는 반환하지 않았습니다. 이전과 마찬가지로 저는 이 도구를 처음 사용하므로 제안 사항이 있으면 기꺼이 받아들이겠습니다!

  • xbootmgr

    • xbootmgr -trace boot -traceflags dispatcher+latency -stackwalk Readythread+threadcreate+profile+cswitch는 부팅 중에 서비스를 디버그하기 위해 실행되었지만 Procmon과 마찬가지로 시스템이 재부팅될 때 문제에 대한 이 추적이 나타나지 않으므로 문제가 발생하지 않습니다. 출력은 상당히 쓸모가 없습니다

이것이 요약입니다. 저는 약간 당황했고 Google이나 OpenAI 모두 여기서 무슨 일이 일어나고 있는지 전혀 모르는 것 같습니다. 따라서 이 문제에 대한 추가 문제 해결이나 이전에 직면한 적이 있는 경우 해결책에 대해 제공할 수 있는 통찰력에 감사드립니다.

답변1

다른 사람에게 문제가 있는 경우 Microsoft의 답변은 다음과 같습니다.

원인(뒷이야기)은 다층적입니다. 이것이 기본적인 정리입니다. 서비스 시작 부팅 시 서비스 시작 시간을 개선하기 위해 WIndows에는 많은 변경 사항이 있었습니다. 이를 통해 일부 서비스를 이전보다 더 일찍 시작할 수 있습니다. 네트워크 종속성이 있고 DAD가 완료되고 인터페이스와 IP를 사용할 준비가 되기 전에 시간이 초과되면 서비스가 시작되지 않을 수 있습니다. 하드웨어 컴퓨터 하드웨어의 개선이 주요 요소입니다. 모든 최신 프로세서에는 다중 코어/스레드가 있어 운영 체제 작업의 병렬 처리가 가능합니다. 프로세서 속도도 크게 향상되었습니다. 이러한 변경을 통해 Windows와 같은 운영 체제는 여러 작업을 더 빠르게 병렬로 수행할 수 있으므로 서비스 시작 시간이 획기적으로 향상됩니다. 사용 가능한 RAM의 양이 빠르게 증가했습니다. 이는 디스크에 대한 페이징이 줄어들고 시작 시간도 향상된다는 의미입니다. 가장 눈에 띄게 개선된 부분은 스토리지입니다. 스토리지는 이제 주로 플래시 기반(SSD)이며 일반적으로 고속 NVMe 상호 연결을 사용합니다. NAS나 SAN과 같은 스토리지 백엔드도 요즘에는 올플래시 기반입니다. 기존 회전 디스크(HDD)와 NVMe SSD 간의 IO, 대기 시간 및 처리량 개선은 약 150배 이상 빠릅니다. 이런 변화는 10년이 채 안 되는 기간에 일어났다. 결과 개선 이전에는 부팅 시 서비스가 시작되는 데 두 자릿수 초가 걸렸습니다. DAD가 Windows에 처음 추가되었을 때는 모든 서비스가 준비되기까지 몇 분이 걸릴 수 있었습니다. DAD에 대한 보상은 필요하지 않았으므로 대부분의 코드는 단순히 IP 주소 상태를 무시했습니다. 서비스 시작 동작의 변화와 최근 하드웨어 개선으로 인해 서비스 시작에 한 자릿수 초가 소요되었습니다. Windows 동작 및 RFC 요구 사항에 따라 IP 주소를 사용할 준비가 되기 훨씬 전입니다. 단순히 IPv4에 대한 DAD 전송 기본값을 1로 변경하는 것은 장기적인 해결책이 아닙니다. 하드웨어와 서비스가 지속적으로 개선됨에 따라 단 1초의 지연만으로도 부팅 시 서비스 오류가 발생할 수 있습니다. 문제가 발생한 서비스는 네트워크 연결을 시도하거나 IP에 바인딩하기 전에 IP 주소 상태를 모니터링하도록 변경되어야 합니다. 알려진 문제 이것은 CSS가 DAD 및 서비스 시작과 관련하여 직면할 수 있는 일반적인 문제 목록입니다. 도메인 계정을 사용하는 서비스를 시작하지 못함 도메인 계정을 사용하는 서비스는 도메인 컨트롤러로 인증을 수행할 준비가 되어 있고 액세스할 수 있는 네트워크에 특별한 종속성을 갖습니다. 인증을 받지 않으면 서비스가 시작되지 않습니다. 서비스가 시작되고 네트워크가 준비되는 데 걸리는 시간보다 빠르게 시간 초과되면(일반적으로 DAD가 완료될 때까지 기다리는 것과 관련) 서비스가 시작되지 않습니다. 이는 SQL Server에서 흔히 볼 수 있지만 로그온을 위해 도메인 계정을 사용하는 모든 서비스에서 발생할 수 있습니다.

이 문제는 DAD 전송 횟수를 줄이거나, DAD를 비활성화하거나, 서비스에서 복구 옵션을 다시 설정하여 해결할 수 있습니다. 해결 방법을 참조하세요.

서비스가 시작 시 IP 주소에 바인딩될 수 없음 이 문제는 서비스가 서비스를 IP 주소에 바인딩하려고 시도하지만 네트워크가 준비되기 전에 시간이 초과되거나 오류가 발생하는 경우 발생합니다. 다시 말하지만 이는 일반적으로 DAD 대기로 인해 발생합니다. 네트워크 스택은 기본 설정 상태가 아닌 IP 주소에 서비스를 바인딩할 수 없습니다. 이 문제는 스풀러(인쇄 서버) 서비스에서 자주 나타납니다. 이와 같은 문제는 DAD를 비활성화하거나 서비스 시작을 "자동(지연된 시작)"으로 설정하여 해결할 수 있습니다. 서비스가 실패/중지되지 않으면 다른 해결 방법이 작동하지 않을 수 있습니다. 서비스는 IP 주소에 대한 바인딩 없이 계속됩니다. 재부팅 시 DNS 서버에서 IPv6 주소가 사라짐 DHCP 클라이언트는 IPv6 DAD가 완료되기 전에 DNS 등록을 요청할 수 있습니다. 이런 일이 발생하면 DNS 클라이언트가 동적 DNS를 업데이트하는 동안 IPv6 주소가 DNS 서버에서 삭제/사라집니다.

이것이 도움이 되기를 바라며 현재로서는 최종 해결책이 없다는 점을 알려드리고 싶습니다.

관련 정보