網路磁碟機啟動的應用程式在 Windows 10 (1703/1809) 上隨機崩潰,報告 0xc0000006 異常或錯誤“無法處理錯誤”

網路磁碟機啟動的應用程式在 Windows 10 (1703/1809) 上隨機崩潰,報告 0xc0000006 異常或錯誤“無法處理錯誤”

介紹

Windows 10(更新 1703 或 1809),從網路磁碟機啟動的應用程式在一段時間後崩潰6095分鐘。在 Windows 7 上應用程式可以完美運作。

該行為已受到實驗室監視數週,涉及多個 32 位元和 16 位元應用程式。

症狀

  • 所有從網路磁碟機啟動應用程式的嘗試都會成功;
  • 所有受影響的 32 位元應用程式 EXE/DLL(威力建設者)記錄了0xc0000006例外事件檢視器
  • 在 16 位元應用程式上(用於 MS-DOS 的 Foxpro 2.6),出現錯誤“無法處理錯誤「或者只是中斷並退出。
  • 偶爾“嘗試報告錯誤 104 時出現致命錯誤 104」發生了。
  • 即使在連續使用過程中也會發生故障(不會有明顯的不活動期);
  • 故障僅發生在Windows 10執行更新 1703 或更新 1809 的 32 位元/64 位元工作站。
  • 收集的分析指出「安全」隨機時期6095第一次啟動和中斷之間的分鐘數;
  • 使用Wireshark, 錯誤STATUS_NETWORK_SESSION_EXPIRED在某些情況下發生故障時會一致記錄。
  • 當多個實例在不同時間啟動時,它們都會在同一秒失敗;
  • 即使網路磁碟機啟動的執行個體最終失敗,從本機磁碟機啟動的執行個體也運作良好;
  • 所有受影響的網站伺服器都在運行Windows 2016 伺服器;
  • 網路驅動器故障後似乎可以正常工作;
  • 在應用程式中斷之前、期間或之後,網路連線似乎永遠不會失敗(連續 PING);

經過測試的實驗室系統配置

  • Windows Server 2016 基礎 (1607)
  • Windows 10 32 位元/64 位元(更新 1703 / 1809)
  • Windows 7(僅限 32 位元)
  • 電纜
  • 轉變

伺服器網路配置

Powershell指令的結果Get-SMBServerConfiguration

AnnounceComment                 : 
AnnounceServer                  : False
AsynchronousCredits             : 512
AuditSmb1Access                 : False
AutoDisconnectTimeout           : 999999
AutoShareServer                 : True
AutoShareWorkstation            : True
CachedOpenLimit                 : 10
DurableHandleV2TimeoutInSeconds : 180
EnableAuthenticateUserSharing   : False
EnableDownlevelTimewarp         : False
EnableForcedLogoff              : True
EnableLeasing                   : False
EnableMultiChannel              : True
EnableOplocks                   : True
EnableSecuritySignature         : True
EnableSMB1Protocol              : True
EnableSMB2Protocol              : True
EnableStrictNameChecking        : True
EncryptData                     : False
IrpStackSize                    : 15
KeepAliveTime                   : 2
MaxChannelPerSession            : 32
MaxMpxCount                     : 50
MaxSessionPerConnection         : 16384
MaxThreadsPerQueue              : 20
MaxWorkItems                    : 1
NullSessionPipes                : netlogon,samr,lsarpc
NullSessionShares               : 
OplockBreakWait                 : 35
PendingClientTimeoutInSeconds   : 120
RejectUnencryptedAccess         : True
RequireSecuritySignature        : True
ServerHidden                    : True
Smb2CreditsMax                  : 8192
Smb2CreditsMin                  : 512
SmbServerNameHardeningLevel     : 0
TreatHostAsStableStorage        : False
ValidateAliasNotCircular        : True
ValidateShareScope              : True
ValidateShareScopeNotAliased    : True
ValidateTargetName              : True

工作站網路配置

Powershell指令的結果Get-SMBClientConfiguration

ConnectionCountPerRssNetworkInterface : 4
DirectoryCacheEntriesMax              : 16
DirectoryCacheEntrySizeMax            : 65536
DirectoryCacheLifetime                : 0
DormantFileLimit                      : 1023
EnableBandwidthThrottling             : True
EnableByteRangeLockingOnReadOnlyFiles : True
EnableInsecureGuestLogons             : True
EnableLargeMtu                        : True
EnableLoadBalanceScaleOut             : True
EnableMultiChannel                    : True
EnableSecuritySignature               : False
ExtendedSessionTimeout                : 1000
FileInfoCacheEntriesMax               : 64
FileInfoCacheLifetime                 : 0
FileNotFoundCacheEntriesMax           : 128
FileNotFoundCacheLifetime             : 5
KeepConn                              : 65535
MaxCmds                               : 50
MaximumConnectionCountPerServer       : 32
OplocksDisabled                       : False
RequireSecuritySignature              : False
SessionTimeout                        : 65535
UseOpportunisticLocking               : False
WindowSizeThreshold                   : 8

我們已經做了什麼

  • 已檢查事件檢視器,即使在SMBCLIENT和SMBSERVER子事件上,但無法找到事件和應用程式故障之間的關聯。
  • 嘗試設定SMB會話逾時設定為65535在工作站上,然後重新啟動,如圖所示哈利克;
  • 嘗試設定SMB保持控制設定為65535在工作站上,然後重新啟動;
  • 停用自動斷開連接(將其更改為-1),然後重新啟動;
  • 嘗試啟用中小企業1在伺服器/工作站上,然後重新啟動;
  • 嘗試在伺服器/工作站上停用防毒軟體 (ESET),然後重新啟動;
  • 停用伺服器/工作站卡上的節能網絡,然後重新啟動;
  • 嘗試停用伺服器/工作站上的防火牆;
  • 案件已接受實驗室監視數週,但沒有成功。

還有其他人面臨這些症狀並能夠提供替代解決方案嗎?

感謝您的關注

答案1

總的來說,Windows 10 1809 中引入了一個新錯誤,微軟在文章中承認了這個錯誤
在 Windows 10 版本 1809 中,已對應的網路磁碟機可能無法重新連接

雖然 Microsoft 已意識到該問題,但預計要到 2019 年某個時候才會進行永久修復。

下面我列出了用戶在網路論壇上提出的一些其他解決方法。


嘗試在客戶端將值設定SessionTimeout為 65535 秒。這可以使用 PowerShell 命令來完成 設定 SmbClientConfiguration -SessionTimeout

它也可能存在於註冊表中
HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\ LANMANWORKSTATION\PARAMETERS\SESSTIMEOUT
(請參閱此舊連結)。

我建議之後重新啟動。


其他可能的解決方法:

  • 將群組原則變更為更新而不是代替群組原則物件 (GPO) 中的磁碟機對應: 使用者配置 > 首選項 > Windows 設定 > 驅動器映射。看關聯。有人報告說可以設定為重新整理

  • 在伺服器和客戶端上執行提升的 cmd 命令:

    net config server /autodisconnect:-1
    
  • 設定網路介面卡的電源選項,可停用「允許電腦關閉此裝置以節省電量」。

  • 有些人報告說,在登入時重新映射網路共用可以解決問題,有些人為此添加了登入腳本。

  • 其他報告建議停用 Windows 10 快速啟動。

答案2

  1. 如果任何伺服器/客戶端盒子在VMWare上運行,請將VMware工具更新到9.0.13或更高版本。 vmxnet3乙太網路驅動程式作為VMware工具包的一部分,應該是1.5.2或更高版本,否則可能會無緣無故地隨機丟包。
  2. 您中間是否有防火牆或負載平衡器?請繞過它然後看看它如何進行。
  3. harrymc 提到的增加 SESSIONTIMEOUT 是一個好方法。我也會這樣做。但我也會出於測試目的這樣做:

下載 TCP Optimizer 4.0,更改客戶端和伺服器端的這些設定並重新啟動兩個盒子:將 MaxConnectionsPer1_0Server 和 MaxConnectionPerServer 增加到 240,將最大 SYNC 重新傳輸增加到 7 MaxUserPort 到 65534 TCPTimedWaitDelay 到 180

登入用戶端框,透過 IP 位址掛載網路磁碟機 \192.168.100.xxx\Source_folder,然後執行相同的應用程式進行測試。

如果問題仍然存在,請分享您正在運行的應用程式。如果是Java應用程序,可能需要一些調整。祝你好運,並期待知道事情進展如何。

相關內容