Önceki bir makalemde, debugger ("Windbg.exe") kurulumunun nasıl yapılacağını görmüş ve "SOS.dll" gibi debugger eklentilerine değinmiştik. "Windbg.exe", "Debugging Tools for Windows" kurulum paketi ile birlikte geliyordu ve bu pakette ilgili "Windows SDK"sının alt paketlerinden biri idi.

"Windbg.exe" ile birlikte aynı kurulumda gelen "cdb.exe", aslında bizim daha alt seviye "debugger"ımız ve arka planda "dbghelp.dll" kullanıyor.  Bu yazımda "cdb.exe" kullanarak debugger komutlarını nasıl çalıştırabiliriz, bunu anlatmaya çalışacağım.

Örneğin, "System.Environment.Exit(Int32)" fonksiyonunun hangi ".net" modülünden çağrılıdığını bulmaya çalışıyorsunuz. Bu durumda "cdb.exe"ye aşağıdaki komutları sıra ile çalıştırtmanız gerekmekte:

.logopen c:\dumps\dbglog.txt;
.load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll
!bpmd mscorlib_ni System.Environment.Exit
g
kL
.logclose;
q

Yukarıdaki komutların çıktıları, ".logopen" ve ".logclose" çağrıları arasında "c:\dumps\dbglog.txt" isimli bir dosyaya kopyalanıyorlar. Yukarıda görüldüğü gibi ilgili "framework"e ait "SOS.dll"ini yükleyip devamında yakalamaya çalıştığımız fonksiyona bir "breakpoint" koyuyoruz. "Breakpoint"e gelindiğinde ise bu fonksiyonu çağıran "callstack"i "kL" komutu ile döküyoruz. Bu sayede log dosyasında aşağıdaki gibi, çağrıyı yapan "callstack"i görebilirsiniz.

0:000> kL
ChildEBP RetAddr 
...
005bef60 73ab3ed1 clr!SystemNative::Exit+0x4f
005bef98 009f0385 mscorlib_ni!System.Environment.Exit(Int32)+0x41
005befa8 5990113e FormsAppforEnvExit!FormsAppforEnvExit.Form1.button1_Click(System.Object, System.EventArgs)+0x25
005befc0 598ffaf0 System_Windows_Forms_ni!System.Windows.Forms.Control.OnClick(System.EventArgs)+0x62
005befd0 59ec1f20 System_Windows_Forms_ni!System.Windows.Forms.Button.OnClick(System.EventArgs)+0x80
...

Bu ve bunun gibi "script"ler birbirinden farklı birçok durum için oluşturulabilir. Birkaç örnek vermek gerekirse, bir "script" yazarak tüm "first chance CLR Exception"larını loglayabilir yada başka bir "custom event"ın ne kadar sıklıkla tetiklendiğini görebilirsiniz. Yada o anda bir "dump" dosyası oluşturabilirsiniz. Aslında bu tip "script"ler, "Live debugging" esnasında yapacak olduğumuz işlemleri taslaklar haline getirmekten ibaret.

Yukarıdaki örnek için uygulanması gereken adımlar ise şu şekilde:

#1- Şu klasörleri yaratıyoruz c:\dumps, c:\debuggers
#2- İlgili mimariye göre "Debugging Tools for Windows" yükleyip, "c:\debuggers" klasörüne içeriğini kopyalıyoruz. Nihayetinde bu klasör altında "cdb.exe" bulunuyor olacak.
#3- Yukarıda belirttiğim komutları "catchEnvExitStack.cfg" dosyasına kaydedip, bu dosyayı "c:\debuggers" altına kopyalıyoruz.
#4- Diyelim ki debug edeceğimiz uygulamamızın adı "MyApp.exe" olsun bu uygulamanın "Process ID"sini taskmanager.exe üzerinden yada "tlist.exe" komutu ile buluyoruz.
#7 Admin yetkileri ile bir komut satırı açıp, "c:\debuggers" altına gidiyoruz ve aşağıdaki komutu çalıştırıyoruz.

cdb.exe -cf catchEnvExitStack.cfg -p PID_OF_MyApp.exe

Diyelim ki "MyApp.exe" nin "process ID"si 3256 olsun bu durumda:

cdb.exe -cf catchEnvExitStack.cfg -p 3256

#10 Fonksiyon çağırılana kadar bekliyoruz, problem oluşana kadar ekranda en son “g” komutu görülmeli..
 

#11 Problem oluşunca script aşağıdaki gibi tamamlanıyor ve log yazılıyor. 

İyi çalışmalar dilerim,

Mert Öztürk

Perfview uygulaması, ".NET Runtime, Architect" ekibinden "Vance Morrison" tarafından yazıldı. Uygulama ile ilgili her türlü gelişme ve yeniliği takip etmek için "Vance Morrison"un kişisel blog'unu takip edebilirsiniz. Ayrıca gine "Channel9" üzerinde de pekçok faydalı video mevcut.

Sizlere bu yazımda geçenlerde keşfettiğim bir özellikten bahsetmek istiyorum. Bu özelliği "help" dosyasını incelerken tesadüfen farkettim. Genellikle "Windbg" üzerinden bir process'e bağlı, "debugging" yaparken "wt" ("watch and trace") komutunu  fonksiyonların birbirlerini nasıl çağırdığını görmek ve iş mantığını anlamak, hangi aşamada hata alındığını tespit etmek gibi pek çok farklı nedenden kullanıyoruz. Öncelikle ilgilendiğimiz fonksiyonu üzerine bir "breakpoint" koyup, bu breakpoint'e gelindiğinde komutu çalıştırarak o fonksiyonun hangi fonksiyonları nasıl çağırdığını görebiliyoruz. Aşağıda örnek bir çıktı mevcut:

0:000> wt                 
Tracing MyModule!myFunction to return address 00401137

  105     0 [  0] MyModule!myFunction
    1     0 [  1]   MyModule!ILT+1555(_printf)
    9     0 [  1]   MyModule!printf
    1     0 [  2]     MyModule!ILT+370(__stbuf)
   11     0 [  2]     MyModule!_stbuf
    1     0 [  3]       MyModule!ILT+1440(__isatty)
   14     0 [  3]       MyModule!_isatty
   50    15 [  2]     MyModule!_stbuf
   17    66 [  1]   MyModule!printf
    1     0 [  2]     MyModule!ILT+980(__output)
   59     0 [  2]     MyModule!_output
   39     0 [  3]       MyModule!write_char
  111    39 [  2]     MyModule!_output
   39     0 [  3]       MyModule!write_char

....

   11     0 [  5]           kernel32!__SEH_epilog4
   54 11675 [  4]         kernel32!ReadFile
  165 11729 [  3]       MyModule!_read
  100 11895 [  2]     MyModule!_filbuf
   91 11996 [  1]   MyModule!fgets
54545 83789 [  0] MyModule!myFunction
    1     0 [  1]   MyModule!ILT+1265(__RTC_CheckEsp)
    2     0 [  1]   MyModule!_RTC_CheckEsp
54547 83782 [  0] MyModule!myFunction

Eğer "wt" çıktısını ( "105 0 [  0] MyModule!myFunction" satırlarının olduğu) bir text dosyasına "*.wt" uzantısı ile kaydedersek bu uzantıyı "Perfview" uygulaması tanıyabilmekte. Ve ilgili fonksiyon çağrılarını "Perview" uygulamasının "Stack Viewer" ekranında inceleyebiliriz. Daha da güzeli; iki farklı "wt" çıktısını menü üzerindeki "Diff" özelliği ile de karşılaştırabilmekteyiz:

Umarım bu özellik performans analizlerinizde faydalı olur.

İyi çalışmalar,
Mert

Windows 8.1 güncellemesini,  "Developer" olarak herkezden önce edinerek, yeni özelliklere göz atabilir ve kişisel asistanınız Cortana ile tanışabilirsiniz. Cortana arka planda Bing'i kullanarak sizin sorularınızı yanıtlayan bir asistan uygulaması. Bunun haricinde, güncelleme ile birlikte birçok yeni özellik de gelmekte.Yükleme için öncelikle AppStudio sitesine gidip, Microsoft live hesabınızla ücretsiz olarak kayıt olmalısınız. Sonrasında yapmanız gerekenler:

- Öncelikle kişisel bilgilerinizi bilgisayarınıza yada Skydrive üzerine yedekleyin, her ihtimale karşı.
- Güncelleme veri taşıma vs. nedeni ile uzun sürüyor bu sebepten 1-2 saatinizi bu işe ayırmalısınız. Bu arada önceki güncellemeler halihazırda yüklenmedi ise onlarda öncesinde yüklenecek. Bu işi biraz daha uzatabilir.
- Wi-fi bağlantısını aktif hale getirin ve telefonda yeterli miktarda şarz olup olmadığını kontrol edin. Mümkünse işlemler sırasında telefon şarza takılı kalsın.
- Windows Store'dan "Preview for Developers" uygulamasını yükleyin, ve daha önce register olduğunuz "AppStudio" üyeliğinizle uygulamaya giriş yapın.
- Uygulamada "Enable Preview update" seçeneğini ("checkbox") işaretleyin ve telefon ayarlarında güncellemeleri kontrol edin. Yükleme işlemi tamamlandıktan sonra, "Blue" güncellemeniz hazır.
- Son olarak "Regional" ayarlarıda değiştirmek gerekiyor. Bölge olarak US(Amerika Birleşik Devletleri) seçip, dil olarak İngilizce seçmeliyiz. Bununla ilgili linkteki makaleyi referans alabilirsiniz.

Eğer sabrederim derseniz elbette yazın gelecek olan "public" sürümü de bekleyebilirsiniz. :)

İyi çalışmalar,
Mert Ozturk

Çoğumuz IIS üzerinde çalışan uygulamalarımızda, oturum bazındaki bilgileri saklamak için "SessionState" modülünü kullanıyoruz. Fakat bu modülü kullanırken dikkat edilmesi gereken bir nokta var. Bu yazıda bu konuya değineceğiz.

Biliyoruz ki bir “ASP.NET” isteği, konfigürasyonu doğrultusunda, bir dizi “HTTP modül”leri içerisinde taşınır ve işlenir. Buna “IIS pipeline” diyoruz. IIS’in gücü bu yapıdan gelmektedir ve birçok farklı teknoloji IIS üzerinde sunulan “Authentication”, “Authorisation” vs. gibi özellikleri kullanırlar.

 Bu modüllerden bir tanesi de “SessionState” modülüdür. “Asp.net” isteği “IIS pipeline” modülleri içerisinde ilerledikçe, işlenmeye hazır hale gelinceye kadar , “HTTPContext” nesnesi içerisine kullanıcı bazında birtakım durum bilgileri yüklenir. Örneğin “SessionStateModule” modülü istek işlenmeden önce “HTTPContext “içerisine session değerlerini bir “Dictionary” nesnesi içerisinden çeker (“Deserialize” işlemi) ve doldurur. İstek işlendikten sonra değişen session bilgileri, gine “SessionStatemodule” tarafından bellek içerisinde geri yüklenir (“serialization” işlemi) ve güncellenmiş “Session” değerleri diğer istekler için hazır hale gelir. . Kullanıcı bazındaki “session” bilgilerine sunucu ve istemci arasında bir cookie içerisinde taşınan “SessionKey” ile erişilir.

Aşağıdaki resimde görüldüğü gibi Session bilgileri, “SessionState” moduna göre, "ASP.NET Cache" içerisinde ("in-proc" modu), Sql suncusu üzerinde ("SQL Server" modu) yada harici bir “aspnet_state.exe” process’i içerisinde ("State Server" modu) tutulabilir. Her bir modun kendine göre avantajları ve dezavantajları vardır. Bu mod aşağıda kısmen gösterdiğim konfigürasyon ile uygulamanın konfigürasyon dosyası üzerinde ("web.config" dosyası) belirtilir.

<sessionState mode="InProc | StateServer | SQLServer />

 Session nesnesine erişim bir “reader/writer”lock üzerinden korunur. Bunun temel amacı, aynı session’a erişmeye çalışan birden fazla istek olduğu zaman, session üzerinde saklanan verinin tutarlılığını korumaya almaktır.

Yazının başında belirttiğim dikkat edilmesi gereken nokta bu kilitleme (“lock”) mekanizması. Varsayılan değer olarak tüm ASP.NET  sayfaları için “EnableSessionState”
değeri “enabled” olarak gelir. Yani sayfa, Session üzerinde "Read/Write" yetkilerine sahiptir. Sayfanın ilk satırındaki “@Page” direktifinde bu değer “ReadOnly” yada “false” olarak değiştirilerek, sayfanın SessionState modülü üzerindeki talepleri değiştirilebilir.

Aynı anda iki istek Session bilgilerini “context” içerisine doldururken “ReadOnly” haklara sahip “aspx” sayfaları, diğerlerine göre daha öncelikli durumdadır, ve “Read/Write” yetkilerine sahip diğer sayfalar bu sebepten beklerler. Aynı anda iki veya daha fazla “ReadOnly” yetkilerine sahip istek ise, “Session” bilgilerine aynı anda erişebilirler. Fakat diğer bir durumda eğer bir “Read/Write” yetkili sayfa Session bilgilerini kilitledi ise, bu durumda diğer hiçbir sayfa, Session üzerindeki işlemler bitinceye kadar “Session” bilgilerine erişemez. Temel olarak “Read/Write” kilit mekanizması bu şekilde çalışır.

Eğer IIS yönetim arayüzünden, birçok isteğin “RequestAcquireState” durumunda beklediğini görmekte isek, bunun sebebi büyük ihtimalle yukarıda belirttiğim koruma mekanizmasıdır.

Bunu kendiniz de test edebilirsiniz. Örneğin aşağıdaki gibi 3 test sayfası hazırlayalım:

SessionPage.aspx : Bu sayfa session’a “Read/Write” yetkileri ile erişen ve session’ı 30 saniye boyunca kilitleyen bir sayfa.

<%@ Page %>

<script language="C#" runat="server">

private void Page_Load(object sender, System.EventArgs e)

{               

Session["SessionLock"] = "Lock Here!";

System.Threading.Thread.Sleep(30000);   

}

</script>

SessionTest.aspx: Bu sayfada “Read/Write” yetkilerine sahip , ve aynı session’ı modifiye etmeye çalışıyor.

<%@ Page %>

<script
language="C#" runat="server">

private void Page_Load(object sender, System.EventArgs e)

{               

Session["SessionLock"]= "Modify Lock";

 }

</script>

 SessionValue.aspx : son olarak sadece “ReadOnly” etkileşime sahip bir sayfa yaratalım.

<%@ Page EnableSessionState="ReadOnly" %>

<script language="C#" runat="server">

private void Page_Load(object sender, System.EventArgs e)

{string sessionLock="";

 if(Session["SessionLock"] != null)

sessionLock = Session["SessionLock"].ToString();

  }

</script>

Devamında bu sayfaları IIS üzerinde bir uygulamaya ekleyelim ve Explorer üzerinden bu sayfalara 10-15 civarında istekte bulunalım.

Test sonucunda aşağıdaki resimden göreceğiniz üzere birçok isteğin beklemeye geçtiğini göreceksiniz.

Bu davranışı farklı şekillerde de test edebilirsiniz. Örneğin “readonly” erişime sahip sayfada “Sleep()” fonksiyonunu uzunca bir süre çağırarak bunun diğer sayfalar üzerindeki etkilerini de test edebilirsiniz.

 (Aşağıdaki ekran IIS yönetim arayüzünde sunucu seviyesindeki özelliklerden “Worker Processes”e tıklandığında, mevcut isteklerin görülebildiği ekrandır.)

 İyi çalışmalar dilerim,

 Mert

31 Ekim itibari ile BizTalk'un son sürümüne ait toplu güncelleştirme paketi yayınlandı.Tüm BizTalk güncelleştirme paketlerini bu link'ten edinebilirsiniz. Güncelleştirmeler toplam 19 farklı soruna çözüm getiriyor. Özellikle benim çok sık olarak karşılaştığım ESB konfigürasyonu sırasında oluşan aşağıdaki hata için çözümde pakete dahil edilmiş:

FIX: "Could not load file or assembly 'Microsoft.BizTalk.Interop.SSOClient

Bunun haricinde bellek ve CPU kullanımı ile ilgili iki farklı performans problemi de düzeltilmiş durumda. Aşağıda tüm gelen güncellemelerin listesini bulabilirsiniz:

Biztalk 2013 CU2:

 Biztalk Adapter Pack 2013 CU1: 

İyi çalışmalar dilerim,

Mert Öztürk

Varsayılan tarih formatı “Windows Server 2012” üzerinde, “Windows Server 2008 R2” den farklı olduğu için, IIS uygulamalarınızı IIS 8.0 üzerine taşırken, uygulamanızda kullanmakta olduğunuz tarih formatlarında değişiklik olduğunu farketmiş olabilirsiniz.

Bunu en basitinden aşağıdaki “aspx” kodunu kullanarak test edebilirsiniz. Bu kod “System.DateTime.Now” çıktısını ekrana dökecektir:

<%@ Page %>

<script language="C#" runat="server">

private void Page_Load(object sender, System.EventArgs e)

{            Response.Write("Default: " + System.DateTime.Now + "<br>");

              Response.Write("Local Time: " + System.DateTime.Now.ToLocalTime() + "<br>");       

              Response.Write("Short Date: " + System.DateTime.Now.ToShortDateString() + "<br>");          

              Response.Write("ToString Default: " + System.DateTime.Now.ToString() + "<br>");

              Response.Write("Universal Time: " + System.DateTime.Now.ToUniversalTime() + "<br>");

              Response.Write("d - Short Date: " + System.DateTime.Now.ToString("d") + "<br>");

              Response.Write("g - General: " + System.DateTime.Now.ToString("g") + "<br>");

                                 Response.Write("Culture : " +System.Threading.Thread.CurrentThread.CurrentCulture.ToString()+ "<br>");              

}

</script>

Bu çıktı IIS 8.0 (Windows Server 2012) üzerinde aşağıdaki şekilde iken: 
  
  
  
Aynı çıktı örneğin IIS 7.5 üzerinde aşağıdaki gibi olacak: 

Peki bu farklılık nereden geliyor?

Bu farklılığın nedeni daha önce belirttiğim gibi “2012 Server” için varsayılan "Short Date" formatı "d.M.yyyy" iken bu format 2008 R2 de "dd.MM.yyyy" şeklinde. Yani registrydeki “sShortDate” bilgisi 2008 R2 ve  2012 Server’da birbirinden farklı. “Control Panel” üzerinden aşağıdaki ekrandan format bilgileri değiştirilebilmekte:

Fakat bu değişiklik sadece “Current User” için etkili oluyor ve “HKCU\Control Panel\International\sShortDate” parametresini değiştiriyor. Denediğim kadarı ile burada yaptığım değişiklik, “application pool” kullanıcısı farklı bir kullanıcı olduğu için etkili olmamakta.

Format bilgileri tüm kullanıcılar için “registry” içerisinde “HKEY_USERS” klasörü içerisinde tutuluyor. Bu klasör içerisinde alt klasörlerde “SID” ("Security Identifier") bazında ayarlar tutulmakta. Aşağıdaki makalede bilinen “SID” numaraları mevcut:

https://support.microsoft.com/kb/243330

Örneğin “S-1-5-18” SID'i "Local System" kullanıcına yada “S-1-5-19” Local Service kullanıcına ait. “S-1-5-21XXXXX” şeklinde olanlar ise administrator yetkili kullanıcılar.

Buradan yola çıkarak eğer örneğin application pool, Local System kullanıcısı ile çalışıyorsa registry de değiştirmemiz gereken yer “HKEY_USERS\S-1-5-18\Control Panel\International” altındaki “sShortDate” değeri olmalı:

Yukarıdaki gibi “sShortDate” değerini dilediğimiz gibi düzenledikten sonra process’in “culture” değerinin yukarıdaki registry’deki “LocaleName” değeri ile aynı olup olmadığını kontrol etmeliyiz. Yani process yukarıdaki örnek için “tr-TR” “culture” ayarında çalışıyor olmalı.. "Web.config" içerisinden culture ayarını aşağıdaki gibi enforse edebiliriz:

<system.web> <globalization               culture="tr-TR"                uiCulture="tr-TR"/> </system.web>

Doğru culture değerini kullanıp kullanmadığımızı anlamak için ise önceki "aspx scipt"inde belirttiğim aşağıdaki kısmı kullanabiliriz.

Response.Write("UI Culture : " +System.Threading.Thread.CurrentThread.CurrentUICulture.ToString()+ "<br>");

Response.Write("Culture : " +System.Threading.Thread.CurrentThread.CurrentCulture.ToString()+ "<br>");    

Son olarak eğer localSystem değilde ApplicationPoolIdentity ile IIS process’i çalışıyorsa ne yapmalıyız diye sorarsanız, benim denemelerimde "built-in Application pool identity" kullacısına ait ayarlar aşağıda gösterdiğim SID altında idi:

Yani en iyisi tüm SID ler içinde “Short date” formatını dilediğiniz gibi değiştirmek. Bu değişikliği yapmanın başka yöntemleri de olabileceğini belirtmek isterim, ama ben daha hızlı olması açısından "registry" ayarları ile oynayarak bu değişikliklerin nasıl yapılabileceğini anlatmaya çalıştım. Yapacağınız registry değişikliklerinden önce ilgili "registry" klasörlerinin bir yedeğini almayı unutmayın.

Teşekkürler,

İyi çalışmalar,

Mert Öztürk

Windows Server 2012 ile gelen IIS 8.0 sürümünde “Client Certificate Authentication” kullanıyorsanız, işler IIS 7.5 ‘dakinden biraz daha farklı yürümekte. Biliyoruz ki IIS, “Client Certificate Authentication” esnasında , istemci tarafına kendi güvendiği “Certificate Authority” lerin yeraldığı bir CTL (Certificate Trust List) gönderiyor. Bu sayede sunucu üzerinde kendi güvendiğiniz Sertifika sağlayıcıları sınırlandırabiliyoruz.

Bağlantıda ki makalede belirttiği gibi IIS 8.0 üzerinde; eğer "Schannel" modülü, “TLS/SSL handshake” esnasında “Trusted Issuer list” gönderimi yapıyorsa 403.7, yapmıyorsa 403.16 alabiliriz. Bu konfigürasyon "Schannel"  kayıt defteri ayarları altında aşağıdaki değişken ile kontrol ediliyor:

 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Value name: SendTrustedIssuerList
Value type: REG_DWORD
Value data: 0 (False)

IIS 8.0 sürümü için “SendTrustedIssuerList” parametresinin varsayılan değeri “0” dır. Yani muhtemelen varsayılan konfigürasyonda 403.16 alıyor olabilirsiniz. Şimdi gelelim bunun sebebine: 

Windows 2012 server için, artık “Client Certificate Policy” akışı registry deki “ClientAuthTrustMode” parametresinin değerine göre farklı çalışıyor. Windows Server 2012 ve Windows 8 işletim sistemlerinde, güvenlik iyileştirmesi olarak,  “Trusted Root Certification Authorities” store’unda bulunan sertifikalar icin self-signed olmasi zorunlulugu getirildi. Nitekim “Root Certificate Authority” sertifikasının self signed olmasi doğası gereği zorunlu. Windows Server 2008 R2 ve Windows 7 işletim sistemlerinde böyle bir zorunluluk yoktu.

Bu nokta’da self-signed olmayanlari “certificate store”dan cikarabilirsiniz ya da asagidaki “ClientAuthTrustMode” registry ayarini “2” ye ayarlayarak davranışı önceki IIS sürümleri ile benzer hale getirebilirsiniz:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]

"ClientAuthTrustMode"=dword:00000002

 Bu registry değerinin alabildiği 3 farklı değer var ve default olarak degeri “0”.

0 : Machine Trust

1 : Exclusive Root Trust

2 : ExclusiveCATrust

Machine Trust ve Exclusive Root Trust degerleri icin “schannel” modülü client ve server tarafindaki sertifikalarda “Trusted Root Cert.s” altında self-signed olmayan sertifika ile karşılaşırsa hata veriyor. Bu değer ExclusiveCATrust olarak ayarlanmış ise Sertifika zinciri düzgün oldugu surece sorun oluşmuyor.

Teşekkürler,

İyi çalışmalar,

Mert Öztürk

Uzunca bir zamandır Biztalk 'un yeni sürümü çıkacak mı çıkmayacak mı tartışmaları son buldu ve Biztalk 2013 sürümü ile tekrar sahnede. Hatırlarsınız önceki yazılarımdan bir tanesinde Biztalk 2010 R2 CTP sürümünü incelemiştik. Fakat görünen o ki Biztalk 'un yeni sürümü 2010 R2 yerine Biztalk 2013 oldu.
Üstelik bu sürüm Azure entegrasyonu ile "Cloud" ile buluşuyor ve IaaS (Infrastructure as a service) ile sunulan hazır VM'ler ile bir saatten kısa bir sürede, platformunuzu oluşturabiliyorsunuz. Detaylı bilgi için aşağıdaki makaleleri inceleyebilirsiniz.

Biztalk 2013'ü Azure üzerinde konfigüre etme:

 https://technet.microsoft.com/en-us/library/jj248689(v=bts.80).aspx

Biztalk 2013 lisanslama modeli:

 https://blogs.biztalk360.com/understand-biztalk-server-2013-licensing/

İyi çalışmalar,

Mert Öztürk

Biliyorsunuz ki IIS sunucusunun son sürümleri ile birlikte gelen FRT (Failed Request Tracing) gibi etkili birçok hata ayıklama yöntemi mevcut. Örneğin FRT; hatanın hangi modülden geldiği ve hatanın içeriğinin ne olduğu ile ilgili detaylı bilgi toplamak için faydalı bir yöntem. Peki diyelim ki HTTP isteği IIS üzerinde beklemediğiniz bir biçimde sonlandırılıyor ve "IIS log"larında, "HTTPErr" loglarında, "FRT" loglarında hiçbir bilgi bulamadınız. Bu durumda ne yapmalısınız. Bu durumda, "HTTP" iletişimi ile ilgili alt seviyelerde  (HTTP.sys kernel seviye sürücü) bir sorunla karşılaşıyor olabilirsiniz. "HTTP" alt seviye modülleri kernel seviyesinde iletişimi bir sebepten kapatıyor olabilir.  Bir sonraki adım olarak IIS 'in bu modüllerinden "ETW trace" toplayabilirsiniz.

Trace konfigürasyonunu, komut satırından, "logman.exe" uygulamasını kullanarak aşağıdaki adımlar ile gerçekleştiriyoruz:

logman -start IISTrace -pf providers.txt -mode Circular -max 20 -ets

Yukarıdaki komut, IIS trace'ini providers.txt (blog'a ekli dosya) içerisinde belirtilen IIS modülleri için, "circular" buffer kullanarak ("-mode circular"), en fazla 20 MB boyutlu bir trace oluşturacak şekilde ( "-max 20") başlatıyor. Trace'lerin "circular" olarak alınıyor olması, problemin her zaman oluşturulamadığı durumdalarda gerekli olabiliyor. "Circular" modunda, olay tekrarlanana kadar alınan "trace" sürekli dosyada kendi maksimum boyutu geçmeyecek şekilde kendi üzerine yazılıyor.

Not: Ekteki dosyadaki provider listesi aşağıdaki gibi , ve dosyaya sağ taraftaki "GUID" bilgilerinin eklenmesi gerekmekte->

IIS: WWW Global                          {d55d3bc9-cba9-44df-827e-132d3a4596c2}
IIS: SSL Filter                          {1fbecc45-c060-4e7c-8a0e-0dbd6116181b}
IIS: Request Monitor                     {3b7b0b4b-4b01-44b4-a95e-3c755719aebf}
IIS: WWW Server                          {3a2a4e84-4c21-4981-ae10-3fda0d9b0f83}
IIS: Active Server Pages (ASP)           {06b94d9a-b15e-456e-a4ef-37c984a2cb4b}
IIS: IISADMIN Global                     {DC1271C2-A0AF-400f-850C-4E42FE16BE1C}
IIS: WWW Isapi Extension                 {a1c2040e-8840-4c31-ba11-9871031a19ea}
HTTP Service Trace                       {dd5ef90a-6398-47a4-ad34-4dcecdef795f}

Problem oluştuğunda ise "trace" i aşağıdaki komut ile durduruyoruz:

logman -stop IISTrace -ets

Ufak bir not: Kopyala yapıştır yaparken “-“ karakteri “–“'e dönüşebilir. Bunları silerek yeniden yazabilirsiniz.

Trace tamamlandığında komutu çalıştırdığınız yerde IISTrace.etl isminde bir trace dosyası oluşmuş olmalı. Bu trace dosyası ilk oluştuğunda okunabilir formatta değildir. Trace'in içeriğini görebilmek için onu formatlamamız gerekiyor. Formatlamak için logparser uygulamasını kullabilirsiniz. Aşağıdaki komutla "IISTrace.etl" dosyasının içerisiğini "csv" formatında kaydediyoruz:

c:\Program Files (x86)\Log Parser 2.2> Logparser "select * into IISTrace.csv from IISTrace.etl" -i:etw -o:csv"
Task completed with parse errors.
Parse errors:
5994 parse errors occurred during processing (To see details about the parse  error(s), execute the command again with a non-zero value for the "-e"  argument)
Statistics:
-----------
Elements processed: 94972
Elements output:    94972
Execution time:     5.82 seconds

Sonrasında trace dosyalarını "Excel" kullanarak aşağıdaki şekilde görüntüleyebilirsiniz:

14 IISRequestNotification PRE_BEGIN_REQUEST_END 3/5/2013 13:06 ContextId={00000000-0000-0000-de03-0080000000f8}|ModuleName=IsapiFilterModule|

NotificationStatus=NOTIFICATION_CONTINUE   
15 IISRequestNotification PRE_BEGIN_REQUEST_START 3/5/2013 13:06 ContextId={00000000-0000-0000-de03-0080000000f8}|ModuleName=RequestMonitorModule     

  
16 IISRequestNotification PRE_BEGIN_REQUEST_END 3/5/2013 13:06 ContextId={00000000-0000-0000-de03-0080000000f8}|ModuleName=RequestMonitorModule|

NotificationStatus=NOTIFICATION_CONTINUE  
17 IISRequestNotification PRE_BEGIN_REQUEST_START 3/5/2013 13:06 ContextId={00000000-0000-0000-de03-0080000000f8}|ModuleName=FailedRequestsTracingModule     

 
18 IISRequestNotification PRE_BEGIN_REQUEST_END 3/5/2013 13:06 ContextId={00000000-0000-0000-de03-0080000000f8}|ModuleName=FailedRequestsTracingModule|

NotificationStatus=NOTIFICATION_CONTINUE 

Aşağıda daha detaylı bilgi edinebileceğiniz birkaç farklı makaleyide ilginize sunuyorum.

"Advanced Debugging and troubleshooting":
https://blogs.msdn.com/b/ntdebugging/archive/2009/12/11/test.aspx

"Capturing and analysing an ETW trace":
https://blogs.msdn.com/b/sudeepg/archive/2009/02/25/capturing-and-analyzing-an-etw-trace-event-tracing-for-windows.aspx 

"Improving debugging and performance tuning with ETW":
https://msdn.microsoft.com/en-us/magazine/cc163437.aspx
 

İyi çalışmalar dilerim,
Mert Öztürk

providers.txt