IIS günlükleri sc-win32-status = 64 değerini gösterir, ancak yalnızca bazı ağlar üzerinden


12

Bir istemci sunucusunda (W2k3, IIS6, .NET 2.0) çalışan bir ASP.NET uygulaması var. FWIW, bu bir Test örneğidir, henüz Üretime taşınmamıştır . Bu nedenle SSL, yük dengeleme vb. Altında çalışmıyor.

Sunucusundaki sayfalardan birine ofisimizden eriştiğimde sayfaya bir kez vurulur. IIS günlüklerini denetlemek (c: WINDOWS \ system32 \ LogFiles \ W3SVC1) bu sayfa için bir GET gösterir, sonra sayfada bir düğmeye basarım ve günlük dosyası bir POST gösterir. Bu şimdiye kadar iyi çalışıyor gibi görünüyor.

Şimdi istemcinin ağına uzaktan eriştiğimde ve yerel makinelerinden birinden sayfaya eriştiğimde, günlük dosyası bir GET gösterir, sonra sayfadaki düğmeye basarım ve günlük aynı saniyede iki POST gösterir . Birincisi durumu gösterir (sc-status, sc-substatus, sc-win32-status) 200 0 64, ikincisi 200 0 0 gösterir.

Günlük dosyasında, her iki POST aynıdır. Temelde günlük gibi görünüyor (dışında bazı verileri maskeli):

#Fields: tarih saat s-ip cs-yöntem cs-uri-kök cs-uri-sorgu s-port cs-kullanıcı adı c-ip cs (Kullanıcı-Aracı) sc-durumu sc-substatus sc-win32-status 
2009-08-11 20:19:32 xxxx GET /File.aspx - 80 - yyyy Mozilla / 4.0 + (uyumlu; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + .NET + CLR 2.0.50727'nin;. + NET + CLR 3.5.21022;. + NET + CLR 3.5.30729;. + NET + CLR 3.0.30618 + MDDR + OfficeLiveConnector.1.4 + OfficeLivePatch .0.0) 200 0 0
2009-08-11 20:19:45 xxxx POST /Dosya.aspx - 80 - yyyy Mozilla / 4.0 + (uyumlu; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + .NET + CLR 2.0.50727'nin;. + NET + CLR 3.5.21022;. + NET + CLR 3.5.30729;. + NET + CLR 3.0.30618 + MDDR + OfficeLiveConnector.1.4 + OfficeLivePatch .0.0) 200 0 64
2009-08-11 20:19:45 xxxx POST /Dosya.aspx - 80 - yyyy Mozilla / 4.0 + (uyumlu; + MSIE + 8.0; + Windows + NT + 6.0; + WOW64; + Trident / 4.0; + SLCC1; + .NET + CLR 2.0.50727'nin;. + NET + CLR 3.5.21022;. + NET + CLR 3.5.30729;. + NET + CLR 3.0.30618 + MDDR + OfficeLiveConnector.1.4 + OfficeLivePatch .0.0) 200 0 0

Sorun şu ki , sayfa iki kez vuruluyor. Veritabanı ilk istek için bir işlem gerçekleştirir, ardından ikinci istek yinelenen bir işlemin gerçekleştirildiğini algılar ve bir hata iletisi atar. Kullanıcılar işlemlerinin başarısız olduğunu düşünüyor, ancak aslında başarılı oldu.

Sc-win32-status 64 hata açıklaması: "Belirtilen ağ adı artık mevcut değil." Bu, her iki POST isteğinin 200 HTTP durumu gösterdiğine, sunucunun isteği sunmakta başarılı olduğuna, ancak istemciye hiçbir zaman bildirilmediğine ve isteği yeniden göndermediğine inanmamı sağlıyor.

  • Bu sorunu nasıl giderebilirim?

  • Yalnızca kendi iç ağlarında bu davranışa neden olabilecek herhangi bir fikir var mı?

  • Bu iki ayrı istemci sitelerinde oluyor, belirtelim, ancak yok değil bizim diğer müşteri sitelerinden altıda gerçekleşmesi veya ofisimizde veya web üzerinden bizim sekiz istemcilerin herhangi bağlanırken.

  • Bunu kendi yerel ağlarında zamanın% 100'ünü, başka bir yerde zamanın% 0'ını tekrarlanabilir yapan ne olabilir?

Güncelleme: Çok az sayıda çoğaltılmış POST isteğinin başlangıçta bildirildiği gibi 64 yerine 99-sc 3232 statüsüne sahip olduğunu gördüm. Sc-win32-status = 995 hata açıklaması: "Bir iş parçacığı çıkışı veya bir uygulama isteği nedeniyle G / Ç işlemi iptal edildi." Bu hiçbir mantıklı değil (Ben kod tam erişim var dikkate alınarak). Hala nasıl veya neden bu sorunun oluştuğunu anlamıyorum, ama yeni hata kodu beni sonuçta bir ağ sorunu olmayabilir inanıyorum yol açıyor ve şimdi rastgele kod hatası olasılığını araştırıyorum.


Tüm günlük alanları sunucuda etkin mi? 2 POST isteği için daha fazla günlük verisi gönderebilir misiniz?
squillman

Tüm alanların etkin olup olmadığından emin değilim, ancak gördüğümüz şeyin bir parçacığını koydum.
wweicker

Sadece bir düşünce, ancak kullanıcılardan biri aynı makinede fiziksel olarak yapıyorsa bu da olur mu? Uzak oturumunuzda belki de gereksiz fare tıklamaları olduğunu düşünüyorum. Düğmeye sekip enter tuşuna basarak etkinleştirirseniz aynı şey olur mu?
squillman

1
Düğme, bir tıklama veya sekme ile veya enter tuşuna basıldığında değiştirildikten sonra kendini gizlemek için inşa edilmiştir, düğme yanlışlıkla "çift tıklamayı" önlemek için görünmez hale gelir. Başlangıçta olduğunu düşündüğümüz şey bu, ancak javascript kullanarak kendini gizlemek için düğmeyi güncelledikten sonra temel ağ sorununu bulduk.
wweicker

Yanıtlar:


18

Bu konuyu şu ana kadar anladım:

  • sc-win32-status 64, “Belirtilen ağ adı artık mevcut değil” anlamına gelir.
  • IIS istemciye son yanıtı gönderdikten sonra, istemciden bir ACK iletisi bekler.
  • Bazen istemciler son ACK'yı sunucuya geri göndermek yerine bağlantıyı sıfırlar. Bu zarif bir bağlantı kapatma değil, bu nedenle IIS "64" kodunu günlüğe kaydeder.
  • Birçok istemci, TIME_WAIT / CLOSE_WAIT içinde bırakmak yerine soketi boşaltmak için, iş bittiğinde bağlantıyı sıfırlar.
  • Proxy'ler bunu diğerlerinden daha fazla yapma eğilimindedir.

Güncelleme: Burada ve burada bazı ilginç bilgiler buldum , bu yüzden temelde herhangi bir kötü biçimlendirme vb. Olmadığından emin olmak için sayfayı yeniden yazdım ve ... sorun artık gitti! Sadece karanlıkta bir atıştı ve sorunu düzeltmenin ne olduğunu kesinlikle söyleyemedim, çünkü bu sadece bazı müşterilerimizi bazı çok özel koşullar altında etkiliyordu ...


Referanslarınızı belirtmeniz bekleniyor. forums.devshed.com/showpost.php?p=1686138&postcount=9
Amit Naidu

2

Aynı sorunu IIS6'dan proxy sunucu aracılığıyla gziplenmiş ikili dosyaları sunmaya çalışırken de yaşadım. Doğrudan web sitesine giderken herhangi bir sorun yaşamadım.

Bu davamın Fiddler'ı bir istemci makinesinde çalıştırarak ve yanıtı inceleyerek neden olduğunu buldum . Fiddler, yanıtın kodlandığını uyarır ve ardından gzip dosyasındaki sihirli sayının doğru olmadığından şikayet eder.

Kodumdaki ikili dosyalar için gzip sıkıştırmasını kapattım ve sorun oluşmadı.


-2

Ben bu konuda uzman değilim ama ben sadece bir ana bilgisayar adı yerine bir IP adresi kullanırken oldu benzer bir sorunla karşılaştı.

Belki bu biraz yardımcı olur ...

Mat.


Sorunu çözmek için ne yaptınız? Ana bilgisayar adını kullanıyoruz, ancak istemci ve sunucu arasında IP'yi kullanan bir proxy sunucusu olabilir.
wweicker
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.