Mark Russinovich ve Windows Internals: Gözlemlenebilirlik ve Güvenilirlik

Mark Russinovich Hâlâ Neden Windows Operasyonlarında Önemli\n\nWindows’u üretimde çalıştırıyorsanız—dizüstü, sunucu, VDI veya bulut VM’lerinde—Mark Russinovich’in çalışmaları günlük operasyonlarda hâlâ görünür. Bu kişilik veya nostalji yüzünden değil; onun popülerleştirdiği kanıta-öncelik veren yaklaşım yüzünden: işletim sisteminin gerçekte ne yaptığını inceleyin, sonra semptomları kanıtla açıklayın.\n\n### Üç sade fikir\n\nGözlemlenebilirlik sistemin ürettiği sinyallerle (“olaylar, izler, sayaçlar”) "şu anda ne oluyor?" sorusuna cevap verebilme yetisidir. Bir servis yavaşladığında veya oturum açmalar takıldığında, gözlemlenebilirlik tahmin ile kesin bilgi arasındaki farktır.\n\nHata ayıklama belirsiz bir problemi (“dondu”) spesifik bir mekaniğe çevirmektir (“bu iş parçacığı I/O’da bekliyor”, “bu süreç sayfa dosyasında aşırı değiş tokuş yapıyor”, “bu DLL enjeksiyonu davranışı değiştirdi”).\n\nGüvenilirlik baskı altında çalışmaya devam edebilme ve öngörülebilir şekilde kurtulabilme yetisidir—daha az olay, daha hızlı geri dönüş ve daha güvenli değişiklikler.\n\n### İç işleyiş bilgisi olayları neden hızlandırır\n\nÇoğu “gizemli kesinti” aslında keşfetmediğiniz Windows davranışlarıdır: handle sızıntıları, kontrolsüz çocuk süreçler, takılı sürücüler, DNS zaman aşmaları, bozuk otomatik başlatma girdileri veya performansa yük getiren güvenlik araçları. Windows iç işleyişine dair temel bir kavrayış (süreçler, iş parçacıkları, handle’lar, servisler, bellek, I/O) kalıpları hızlıca tanımanıza ve sorun kaybolmadan önce doğru kanıtı toplamanıza yardımcı olur.\n\n### Bu makale size neler yaptıracak\n\nOperasyonlara uygun, pratik iş akışlarına odaklanacağız: \n\n- Sysinternals araçları (özellikle Process Explorer ve Process Monitor) ile hızlı, az zahmetli görünürlük\n- Loglar yetmediğinde ve yüksek doğruluklu "ne oldu" zaman çizelgelerine ihtiyaç duyduğunuzda ETW izleme\n- Hataları eyleme dönüştürülebilir kök nedenlere çevirmek için WinDbg ve çökme/takılma dökümleri\n\nAmaç sizi çekirdek mühendisine dönüştürmek değil. Amaç Windows olaylarını daha kısa, daha sakin ve daha kolay açıklanabilir hale getirmek—böylece düzeltmeler daha güvenli ve tekrarlanabilir olur.\n\n## Windows İç İşleyişi: Bir Sorun Giderme Süpergücü\n\nWindows “internals”, Windows’un gerçek işi yapmak için kullandığı mekanizmaların tümüdür: iş parçacıklarını zamanlama, belleği yönetme, servisleri başlatma, sürücüleri yükleme, dosya ve kayıt defteri etkinliklerini işleme ve güvenlik sınırlarını uygulama. Pratik vaadi basittir: işletim sisteminin ne yaptığını anladığınızda, tahmin etmeyi bırakarak açıklamaya başlarsınız.\n\nBu önemlidir çünkü çoğu operasyonel belirti dolaylıdır. “Makine yavaş” CPU içeriği, tek bir sıcak iş parçacığı, sürücü kesme fırtınası, paging baskısı veya antivirüs filtresinin dosya I/O’sunu engellemesi olabilir. “Donuyor” bir deadlock, takılı ağ çağrısı, depolama zaman aşması veya bir servisin bağımlılığı beklemesi olabilir. Açılış sorunları bozuk bir autorun girdisi, başarısız sürücü yüklemesi veya asla bitmeyen bir politika betiği olabilir. İç işleyiş bilgisi belirsiz şikayetleri test edilebilir hipotezlere dönüştürür.\n\n### Kullanıcı modu vs. kernel modu (faydalı olacak kadar)\n\nGenel olarak, kullanıcı modu çoğu uygulama ve servisin çalıştığı yerdir. Onlar çöktüğünde genellikle sadece kendileri etkilenir. Kernel modu ise Windows’un kendisinin ve sürücülerin çalıştığı yerdir; burada problemler tüm sistemi kilitleyebilir, bir bugcheck’e (mavi ekran) neden olabilir veya sessizce güvenilirliği bozabilir.\n\nBu ayrımı derin teoriye gerek kalmadan kullanın—sadece kanıt seçiminde size yol göstersin. Bir uygulamanın CPU’yu tüketmesi genellikle kullanıcı moduna işaret eder; tekrar eden depolama sıfırlamaları veya ağ sürücüsü sorunları kernel modu işaretleri olabilir.\n\n### Kanıta-önce hata gidermesi\n\nRussinovich’in zihniyeti—Sysinternals ve Windows Internals’ta görülen—"önce kanıt"tir. Ayarları değiştirmeden, rastgele yeniden başlatmadan veya yeniden kurmadan önce sistemin ne yaptığını yakalayın: hangi süreç, hangi iş parçacığı, hangi handle, hangi kayıt anahtarı, hangi ağ bağlantısı, hangi sürücü, hangi olay.\n\n"Windows şu anda ne yapıyor ve neden?" sorusunu cevaplayabildiğinizde, düzeltmeler daha küçük, daha güvenli ve gerekçelendirilebilir olur—ve güvenilirlik çalışması reaktif yangın söndürmeden çıkar.\n\n## Sysinternals Yaklaşımı: Görünmeyeni Görünür Kılmak\n\nSysinternals, Windows için bir "görünürlük araç takımı" olarak anlaşılmalıdır: küçük, taşınabilir yardımcılar sistemin gerçekte ne yaptığını süreç süreç, handle handle, kayıt anahtarı anahtarı gösterir. Windows’u kara kutu gibi görmek yerine, Sysinternals semptomların arkasındaki davranışı gözlemlemenizi sağlar: “uygulama yavaş”, “CPU yüksek” veya “sunucu bağlantıları koparıyor” gibi durumları açıklamaya yardımcı olur.\n\n### Güven ama doğrula: tahmin etme, ölç\n\nOperasyonel acı çoğunlukla makul görünen tahminlerden gelir: muhtemelen DNS’dir, muhtemelen antivirüs, Windows Update yine takıldı. Sysinternals zihniyeti basittir: içgüdülerinizi bir hipotez oluşturmak için kullanın, sonra onu kanıtla.\n\nHangi işlemin CPU tükettiğini, hangi iş parçacığının beklediğini, hangi dosya yolunun hedeflendiğini veya hangi kayıt değerinin sürekli yeniden yazıldığını gördüğünüzde, fikir tartışmasını bırakıp nedenleri daraltırsınız. Bu değişim—anlatıdan ölçüme—iç işleyiş bilgisini pratik kılar.\n\n### Canlı olaylarda Sysinternals’ın parlaklığı\n\nBu araçlar “her şey yanıyor” anı için inşa edilmiştir:\n\n- Düşük sürtünme: birçok araç kurulum gerektirmeden çalışır ve hızlı başlar.\n- Hızlı geri bildirim: bir teoriyi dakikalar içinde doğrulayabilir veya çürütebilirsiniz.\n- Odaklanmış görünürlük: her yardımcı belirli soru sınıfını cevaplar (süreçler, başlangıç öğeleri, ağ uç noktaları, bellek kullanımı).\n\nUzun bir kurulum döngüsüne, ağır bir ajan dağıtımına veya daha iyi veri toplamak için yeniden başlatmaya zamanınız yokken bu önem kazanır.\n\n### Güvenli kullanım ilkeleri\n\nSysinternals güçlüdür ve güç dikkat gerektirir:\n\n- Gerektikçe çalıştırın: önce salt-okuma gözlemiyle başlayın; yetki yükseltmeyi yalnızca gerektiğinde yapın.\n- Ne yaptığınızı belgeleyin: zaman damgaları, filtreler ve alınan aksiyonları kaydedin ki bulgular tekrar üretilebilir olsun.\n- Aksaklığı azaltın: "düzeltmeye çalışmak" yerine kanıt yakalamayı (ekran görüntüleri, loglar, dışa aktarılan izler) tercih edin.\n- Dikkatli değiştirin: bir ayarı değiştirmek veya bir süreci sonlandırmak zorundaysanız, nedeni ve beklenen sonucu not edin, sonra sonucu doğrulayın.\n\nBu şekilde kullanıldığında, Sysinternals disiplinli bir yöntem olur: görünmeyeni gözlemle, gerçeği ölç ve umuttan ziyade gerekçeyle değişiklik yap.\n\n## Process Explorer ve Process Monitor: Günlük Hata Ayıklama Çifti\n\nEğer yönetici araç kutunuzda sadece iki Sysinternals aracı tutacaksanız, bunlar Process Explorer ve Process Monitor olsun. Birlikte, ajan, yeniden başlatma veya ağır kurulum gerektirmeden en sık sorulan “Windows şu anda ne yapıyor?” sorularını cevaplarlar.\n\n### Process Explorer: saniyeler içinde hızlı cevaplar\n\nProcess Explorer, Görev Yöneticisi’ne X-ışını görüşü katan bir araçtır. Bir makine yavaş veya kararsızsa hangi süreç sorumlu olduğunu ve bununla nelerin ilişkili olduğunu bulmanıza yardımcı olur.\n\nÖzellikle kullanışlıdır:\n\n- CPU ve iş parçacıkları: Hangi süreç CPU yakıyor, tek bir sıcak iş parçacığı mı yoksa birkaçı mı?\n- Ebeveyn/çocuk ilişkileri: Süreci ne başlattı (servis, zamanlanmış görev, güncelleştirici veya kullanıcı eylemi)?\n- DLL’ler ve handle’lar: Hangi modüller yüklü ve süreç hangi dosya/kayıt/pipe’ları açık tutuyor?\n\nSon nokta güvenilirlik için süper güçtür: “Neden bu dosyayı silemiyorum?” genellikle “Bu servis o dosyaya açık bir handle tutuyor” olur.\n\n### Process Monitor: tam aktivite izi\n\nProcess Monitor (Procmon), dosya sistemi, kayıt defteri ve süreç/iş parçacığı etkinlikleri boyunca ayrıntılı olaylar yakalar. "Uygulama takıldığında ne değişti?" veya "disk her 10 dakikada bir neden vuraıyor?" gibi sorular için ideal araçtır.\n\nYakalamaya başlamadan önce soruyu çerçeveleyin:\n\n- Belirti nedir (yavaş oturum açma, yüksek disk, çökme, erişim reddedildi)?\n- Ne zaman oluyor (başlangıçta, 09:00'da, uyku sonrası)?\n- Hangi makine ve kullanıcı bağlamı (sadece bir sunucu, sadece bir kullanıcı profili, sadece VPN'de mi)?\n\n### Sadece ihtiyacınız olanı yakalayın (gürültü düşmandır)\n\nProcmon sizi bunaltabilir; bu yüzden agresif filtreleme ile başlayın:\n\n- Belirli bir Process Name veya PID ile filtreleyin.\n- İlgili yol için Include kuralları kullanın (ör. bir yapılandırma klasörü) ve geri kalanını hariç tutun.\n- Semptom çevresinde kısa bir pencere yakalayın, sonra durdurun.\n\n### Elde ettikleriniz\n\nSık kazanımlar çok pratiktir: eksik bir kayıt anahtarını tekrar tekrar sorgulayan hatalı bir servis tespit etmek, binlerce dosyaya dokunan gerçek zamanlı bir taramanın neden olduğu aşırı disk kullanımı bulmak veya bir DLL yükleme denemesinin eksik olması (“NAME NOT FOUND”) yüzünden bir uygulamanın sadece bir makinede başlamadığını açıklamak gibi.\n\n## Autoruns, TCPView, RAMMap: Ağır Kurulum Olmadan Hızlı İpuçları\n\nBir Windows makinesi “garip hissettiğinde”, tam bir izleme yığınına ihtiyacınız olmaz. Bir küçük Sysinternals seti üç pratik soruyu hızlı yanıtlayabilir: Ne otomatik başlıyor? Kim neyle konuşuyor? Bellek nereye gitti?\n\n### Autoruns: güvenilirlik açılışta başlar\n\nAutoruns, kullanıcı açıkça çalıştırmasa bile nelerin başlayabileceğini anlamanın en hızlı yoludur: servisler, zamanlanmış görevler, kabuk uzantıları, sürücüler ve daha fazlası.\n\nNeden güvenilirlik için önemli: başlangıç öğeleri yavaş açılışların, aralıklı takılmaların ve yalnızca oturum açıldığında görülen CPU sıçramalarının yaygın kaynaklarıdır. Bir kararsız güncelleştirici, eski sürücü yardımcı programı veya bozuk kabuk uzantısı tüm sistemi bozabilir.\n\nPratik ipucu: imzasız, yakın zamanda eklenmiş veya yüklenemeyen girdilere odaklanın. Bir girdiyi devre dışı bırakmak sistemi istikrarlı hale getiriyorsa, belirsiz bir belirtiden güncelleme, kaldırma veya değiştirme gerektiren belirli bir bileşene indirgemiş olursunuz.\n\n### TCPView: kim dinliyor, kim konuşuyor doğrulayın\n\nTCPView size süreç adlarına ve PID’lere bağlanmış aktif bağlantılar ve dinleyicilerin anlık haritasını verir. Hızlı kontroller için idealdir:\n\n- Beklenmeyen LISTENING portlar (özellikle sessiz olması gereken sunucularda)\n- Olağandışı sayıda bağlantıya sahip tek bir süreç\n- CPU veya gecikme şikayetleriyle korelasyon gösteren hızlı bağlantı devinimi\n\nGüvenlik dışı incelemelerde bile, bu kaçan ajanları, yanlış yapılandırılmış proxy’leri veya uygulamanın yavaş göründüğü ama asıl sorunun ağ davranışı olduğu “yeniden deneme fırtınalarını” ortaya çıkarabilir.\n\n### RAMMap: tahmin yerine bellek baskısı\n\nRAMMap, belleğin gerçekten nereye ayrıldığını göstererek bellek baskısını yorumlamanıza yardımcı olur.\n\nKullanışlı temel ayrım:\n\n- Working set: çalışan süreçler tarafından aktif olarak kullanılan fiziksel bellek\n- Cache / standby: Windows’un hız için tuttuğu veri (kendiliğinden kötü değil)\n\nKullanıcılar “az bellek” bildirirken Görev Yöneticisi kafa karıştırıcı görünüyorsa, RAMMap gerçek süreç büyümesi mi yoksa yoğun dosya önbelleği mi olduğunu doğrulayabilir.\n\n### İsteğe bağlı: sızıntı şüphesinde Handle ve VMMap\n\nBir uygulama günler içinde yavaşlıyorsa, Handle artan handle sayısını ortaya koyabilir (klasik bir sızıntı paterni). VMMap bellek kullanımı tuhaf olduğunda—parçalanma, büyük rezerve bölgeler veya basit “private bytes” olarak görünmeyen tahsisler—yardımcı olur.\n\n### Tekrarlanabilir ilk 15 dakika kontrol listesi\n\n1. Autoruns: yeni/imzasız girdileri tarayın; şüpheli öğeleri birer birer devre dışı bırakın.\n2. TCPView: beklenen dinleyicileri doğrulayın; en çok bağlantı sahibi süreçleri belirleyin.\n3. RAMMap: baskının çalışma seti büyümesi mi yoksa önbellek/standby mi olduğunu kontrol edin.\n4. Zaman tabanlı belirtiler varsa: hızlı bir “önce/sonra” anlık görüntüsü yakalayın (sayılar, portlar, bellek toplamları).\n5. Büyüme barizse: sızıntı desenini doğrulamak için Handle/VMMap kullanın.\n6. Şüpheli bileşeni ve kanıtları yazın ki düzeltme hedefli olsun, tahmine dayalı değil.\n\n## Loglardan ETW’ye: Windows’ta Gerçek Gözlemlenebilirlik Kurmak\n\nWindows operasyonu genellikle elde etmesi kolay olanla başlar: Event Viewer ve birkaç Görev Yöneticisi ekran görüntüsü. Bu kırıntılar için iyidir, ama güvenilir olay müdahalesi üç tamamlayıcı sinyal türüne ihtiyaç duyar: loglar (ne oldu), metrikler (etki ne kadar kötü), ve izler (sistem anlık olarak ne yapıyordu).\n\n### Olay günlükleri: iyi ipuçları, kusurlu kapsama\n\nWindows olay günlükleri kimlik, servis yaşam döngüsü, politika değişiklikleri ve uygulama düzeyi hatalar için mükemmeldir. Ancak düzensizdir: bazı bileşenler yoğun log kaydederken bazıları seyrektir ve mesaj metni belirsiz olabilir (“Uygulama yanıt vermeyi durdurdu”). Bunları zaman çizelgesi çapağı olarak görün, tüm hikâye olarak değil.\n\nYaygın kazanımlar:

• Servis başlatma/durdurma ve çökme olayları

• Kimlik doğrulama ve yetkilendirme olayları

• Uygulama istisnaları (uygulamalar bunları kaydettiğinde)\n\n### Kesinti sırasında metrikler: genellikle önemli olan birkaç değer\n\nPerformans sayaçları makinenin “sağlıklı mı?” sorusuna cevap verir. Kesinti sırasında şu değerlerle başlayın:\n\n- CPU: kalıcı yüksek CPU, hazır zaman (VM’ler), süreç başına CPU\n- Disk: sıra uzunluğu, okuma/yazma gecikmesi, IOPS, boş alan\n- Bellek: committed bytes, commit limit, hard faults/sec, pool kullanımı\n- Ağ: retransmit’ler, hatalar, byte/sn, bağlantı sayıları\n\nMetrikler neden bir sıçrama olduğunu söylemez, ama ne zaman başladığını ve iyileşip iyileşmediğini söyler.\n\n### ETW basitçe: yapılandırılmış, yüksek hacimli izleme\n\nEvent Tracing for Windows (ETW), Windows’un yerleşik uçuş kaydedicisidir. Ad-hoc metin mesajları yerine, ETW çekirdekten, sürücülerden ve servislerden yüksek hacimde yapılandırılmış olaylar gönderir—süreç/iş parçacığı etkinliği, dosya I/O, kayıt erişimi, TCP/IP, zamanlama ve daha fazlası. Birçok “gizemli duraksama” burada açıklanabilir.\n\n### Her şeyi toplamadan sinyalleri seçmek\n\nPratik bir kural:\n\n- Ayrık olaylar için logları kullanın (çökme, yeniden başlatma, kimlik hatası).\n- Etkiyi tespit ve nicelleştirmek için metrikleri kullanın (gecikme, doygunluk).\n- Nedensellik gerektiğinde ETW kullanın (hangi I/O, hangi çağrı yolu).\n\n"Her şeyi daima açık tut" yaklaşımından kaçının. Küçük bir sürekli baz (ana loglar + temel metrikler) bulundurun ve olay sırasında kısa, hedefli ETW yakalamaları yapın.\n\n### Zaman korelasyonu süpergüçtür\n\nEn hızlı teşhisler üç saati hizaya getirmekten gelir: kullanıcı raporu (“10:42’de dondu”), metriklerdeki kırılma (CPU/disk sıçraması) ve log/ETW olayları aynı zaman damgasında. Verileriniz ortak bir zaman tabanını paylaştığında, kesintiler tahmin olmaktan çıkar ve doğrulanabilir hikâyelere dönüşür.\n\n## Sysmon Telemetrisi: Güvenlik Sinyalleri Aynı Zamanda Güvenilirliğe Yardımcı Olur\n\nVarsayılan Windows olay günlükleri faydalıdır, ama genellikle operatörlerin beklenmedik bir değiştiğinde "neden şimdi?" dediği ayrıntıları kaçırır. Sysmon (System Monitor) bu boşluğu doldurur; özellikle başlatmalar, kalıcılık ve sürücü davranışı etrafında daha yüksek doğrulukta süreç ve sistem etkinliği kaydeder.\n\n### Sysmon’un ekledikleri (varsayılan logların ötesinde)\n\nSysmon’un gücü bağlamdır. Sadece "bir servis başladı" demek yerine genellikle hangi sürecin başlattığını, tam komut satırını, ebeveyn süreci, hash’leri, kullanıcı hesabını ve korelasyon için temiz zaman damgalarını görebilirsiniz.\n\nBu güvenilirlik çalışmaları için değerlidir çünkü birçok olay küçük değişikliklerle başlar: yeni bir zamanlanmış görev, sessiz bir güncelleştirici, yanlışlıkla çalışan bir betik veya kötü davranan bir sürücü.\n\n### Minimal konfigürasyon: amaçlı olarak dar başlayın\n\nHer şeyi kaydeden bir Sysmon konfigürasyonu genellikle iyi bir ilk hamle değildir. Dar, güvenilirlik odaklı bir setle başlayın ve sadece net sorular olduğunda genişletin.\n\nİyi başlangıç adayları:

• Süreç oluşturma (beklenmeyen başlatmalar, şüpheli komut satırları)

• Sürücü yükü (yeni veya değişen kernel bileşenleri)

• Image/DLL yükleme (bağımlılık sorunları için seçici kullanın)

• Servis ve zamanlanmış görev etkinliği (kalıcılık ve arka plan değişiklikleri)

• Ağ bağlantıları / DNS (hacmi yönetmek için sadece belirli soruşturmalar için etkinleştirin)

Sinleri okunabilir tutmak için hedefli include kuralları (kritik yollar, bilinen servis hesapları, ana sunucular) ve dikkatle seçilmiş exclude kuralları (gürültülü güncelleyiciler, güvenilen yönetim ajanları) kullanarak ayarlayın.\n\n### Gerçekçi güvenilirlik kullanım durumları\n\nSysmon sıkça şu tür “gizemli değişiklik” senaryolarını doğrulamada veya ekarte etmede yardımcı olur:\n\n- CPU sıçramalarından hemen önce bir servis hesabı altında doğan yeni bir yardımcı süreç\n- Yama döngüsünden sonra bir servis ikilisinin yolu veya başlatma türünün değişmesi\n- Yeni takılmalar, bugcheck’ler veya depolama/ağ sıfırlamalarıyla eşzamanlı sürücü güncellemesi\n\n### Operasyonel uyarılar\n\nTemsili makinelerde etkiyi test edin. Sysmon disk I/O ve olay hacmini artırabilir; merkezi toplama hızla maliyetli olabilir.\n\nAyrıca komut satırları, kullanıcı adları ve yollar gibi alanları hassas kabul edin. Geniş kapsamlı dağıtımdan önce erişim kontrolleri, saklama sınırları ve filtreleme uygulayın.\n\n### Tamamlayıcıdır, yerine geçmez\n\nSysmon yüksek değerli kırıntılar olarak en iyi iş görür. Derin performans soruları için ETW, trend tespiti için metrikler ve olay notlarını disiplinli tutarak neyin değiştiğini, neyin bozulduğunu ve nasıl düzelttiğinizi bağlayın.\n\n## WinDbg ve Dökümler: Çökme ve Takılmaları Cevaplara Dönüştürmek\n\nBir şey “sadece çöküyor” ise, en değerli artefakt genellikle bir dökümdür: belleğin anlık görüntüsü ve başarısızlık anında neyin çalıştığını yeniden kurmak için yeterli yürütme durumu. Logların aksine dökümler doğru mesajı önceden tahmin etmenizi gerektirmez—olayı takiben kanıtı yakalarlar.\n\n### Çökme dökümleri nedir ve neden istersiniz\n\n- Uygulama çökme dökümleri (kullanıcı modu) tek bir süreci kaydeder. Bir servis öldüğünde idealdir.\n- Kernel dökümleri (sistem çapında) bugcheck (BSOD) için kullanılır ve OS durumunu, sürücüleri ve kernel iş parçacıklarını içerir.\n\nDökümler belirli bir modülü, çağrı yolunu ve hata tipini (erişim ihlali, heap bozulması, deadlock, sürücü hatası) gösterebilir; semptomlardan bunu çıkarmak zordur.\n\n### WinDbg temelleri: semboller, stack’ler ve “neyin başarısız olduğu”\n\nWinDbg bir dökümü hikâyeye dönüştürür. Temel noktalar:\n\n- Semboller ham adresleri fonksiyon isimlerine ve satır bilgilerine eşler. Doğru semboller olmadan analiz çabuk tahmine dönüşür.\n- Stack izleri çökme yolunu veya “takılı” bir iş parçacığının mevcut durumunu gösterir.\n- Amaç başarısız bileşeni saptamaktır: kendi kodunuz, bir bağımlılık DLL’si, bir sürücü, antivirüs shim’i, grafik yığını vb.\n\nTipik iş akışı: dökümü aç → sembolleri yükle → otomatik analiz çalıştır → üst stack’leri ve ilgili modülleri doğrula.\n\n### Çökme vs BSOD vs takılma: kategorileri karıştırmayın\n\n- Bugcheck (BSOD): tüm sistem durur. Kernel dökümleri ve sürücü kökenli analiz bekleyin.\n- Uygulama çökmesi: tek bir süreç sonlanır. Kullanıcı modu dökümleri ve istisna kodu bekleyin.\n- Takılma: hiçbir şey “çökmez”, ama iş durur. Hangi iş parçacıklarının ne için beklediğine dair kanıt gerekir.\n\n### Takılmalar kanıt ister: stack’ler, beklemeler ve kilitler\n\n"Dondu" tanısı semptomdur, teşhis değil. Takılmalar için uygulama yanıt vermezken döküm alın ve inceleyin:\n\n- Her iş parçacığının stack’i ne yapıyor gösterir.\n- Bekleme nedenleri (I/O, RPC, mutex/critical section, ağ) incelenir.\n- Kilitlenme/çekişme kalıpları—çoğu zaman “takılı” UI iş parçacığı başka yerde bloke olmuş bir işçi iş parçacığını bekler.\n\n### Gerçekçi beklentiler: kendiniz teşhis vs. yükseltme\n\nTek modülde tekrarlayan çökme, bariz deadlock veya belirli bir DLL/sürücü ile güçlü korelasyon gibi açık sorunları sıklıkla kendiniz teşhis edebilirsiniz. Dökümler üçüncü taraf sürücüler/güvenlik yazılımını, kernel bileşenlerini veya sembol/kaynak erişimi eksikliğini işaret ediyorsa yükseltin—o zaman satıcı (veya Microsoft) tam zinciri yorumlamak için gerekli olabilir.\n\n## Yaygın Hata Kalıpları ve İç İşleyişin Açıklamaları\n\nPek çok "gizemli Windows problemi" aynı kalıpları tekrarlar. Tahmin ile düzeltme arasındaki fark, OS’nin ne yaptığını anlamaktır—Internals/Sysinternals zihniyeti bunu görmenize yardımcı olur.\n\n### Bellek sızıntıları: working set vs. commit\n\n“Uygulama bellek sızdırıyor” dendiğinde genellikle iki şeyden biri kastedilir.\n\nWorking set işlem için şu anda fiziksel RAM ile eşlenen bellek. Baskı altında Windows tarafından kırpılıp geri alınabilir.\n\nCommit sistemin RAM veya sayfa dosyası ile desteklemeyi vaat ettiği sanal bellek miktarıdır. Eğer commit artmaya devam ediyorsa, gerçek bir sızıntı riski vardır: nihayet commit limitine ulaşır ve tahsisler başarısız olmaya başlar veya host kararsızlaşır.\n\nYaygın bir semptom: Görev Yöneticisi “kullanılabilir RAM” gösterirken makine yine de yavaşlar—çünkü sınırlayıcı olan boş RAM değil commit’dir.\n\n### Handle sızıntıları: rastgele görünen yavaş başarısızlık\n\nBir handle dosya, kayıt anahtarı, olay, section vb. gibi bir OS nesnesine referanstır. Bir servis handle sızdırırsa, saatler veya günler sorunsuz çalışabilir, sonra garip hatalarla karşılaşmaya başlar (dosyayı açamama, iş parçacığı oluşturamama, bağlantıları kabul edememe) çünkü süreç başına handle sayıları artar.\n\nProcess Explorer’da handle sayısı trendlerini izleyin. Sürekli yükselen bir eğri servis “bir şeyi kapatmayı unutuyor” sinyalidir.\n\n### Disk ve dosya sistemi sorunları: gecikme, yeniden denemeler, filtre sürücüler\n\nDepolama problemleri her zaman yüksek verim olarak görünmez; genellikle yüksek gecikme ve yeniden denemeler şeklinde kendini gösterir. Process Monitor’da arayın:\n\n- Tekrarlayan CreateFile/ReadFile işlemleri\n- Uzun süreli I/O olayları\n- Çok sayıda NAME NOT FOUND / PATH NOT FOUND gürültüsü (yanlış yapılandırılmış yollar)\n\nAyrıca filtre sürücülerine (AV, yedekleme, DLP) dikkat edin. Bunlar dosya I/O yoluna ek gecikme veya hata ekleyebilir; uygulama “yanlış yapmıyor” olsa bile sonuç ortaya çıkabilir.\n\n### CPU sıçramaları: tek sıcak süreç vs. çekişme\n\nTek bir sıcak süreç kolaydır: bir yürütülebilir CPU yakar.\n\nSistem çapında çekişme daha zordur: CPU yüksek çünkü birçok iş parçacığı çalıştırılabilir durumda ve kilitler/disk/bellek için yarışıyor. İç işleyiş düşüncesi sizi şu soruyu sormaya iter: “CPU faydalı iş mi yapıyor yoksa başka yerde bloke olup döngü mü dönüyor?”\n\n### Ağ problemleri: bağlantının sahibi kim?\n\nZaman aşımı olduğunda süreç → bağlantı haritasını TCPView veya Process Explorer ile çıkarın. Yanlış süreç sokete sahipse somut fail bulunmuştur. Doğru süreç sahipse, SYN yeniden denemeleri, uzun süreli boşta kalan bağlantılar veya kısa ömürlü çok sayıda giden deneme gibi desenlere bakın—bu durumda sorun ağ/DNS/firewall/proxy olabilir, uygulamanın kendisi değil.\n\n## Pratik Bir İş Akışı: Gözlemle → Yakala → Açıkla → Düzelt\n\nHer olay aynı yolu izlediğinde güvenilirlik çalışması kolaylaşır. Amaç “daha fazla araç çalıştırmak” değil—tutarlı kanıtlarla daha iyi kararlar almak.\n\n### 1) Tekrarla (veya tetikleyiciyi tanımla)\n\n“Kötü” halini bir cümleyle yazın: “Büyük bir dosya kaydederken uygulama 30–60 saniye donuyor” veya “CPU her 10 dakikada bir %100’e çıkıyor.” Tekrar edilebiliyorsa, isteğe bağlı olarak yeniden üretin; edilemiyorsa tetikleyiciyi tanımlayın (zaman penceresi, yük, kullanıcı eylemi).\n\n### 2) Gözlemle (önce hafif)\n\nAğır veri toplamadan önce semptomu ve kapsamı doğrulayın:\n\n- Tek makine mi yoksa birden fazla mı?\n- Tek süreç mi yoksa tüm host mu?\n- Performans sorunu mu, çökme mi, takılma mı?\n\nHızlı kontroller (Görev Yöneticisi, Process Explorer, temel sayaçlar) bir sonraki adımda ne yakalayacağınızı seçmenize yardım eder.\n\n### 3) Yakala (iyi bir vaka dosyası oluştur)\n\nOlayı ekibe teslim edilecek bir vaka dosyası gibi yakalayın. İyi bir vaka dosyası genellikle şunları içerir:\n\n- Zaman damgaları (başlangıç/bitiş, zaman dilimi, sıklık)\n- Sürümler (Windows build, uygulama sürümü, sürücü sürümleri)\n- Konfigürasyon (özellik bayrakları, politikalar, ortam değişkenleri, güvenlik araçları)\n- İzler (Procmon filtreleri, ETW oturum adı, süre)\n- Dökümler (takılma/çökmeler: full vs. minidump, hangi süreç, nasıl tetiklendiği)

Yakalamaları kısa ve hedefli tutun. Hata penceresini kapsayan 60 saniyelik bir iz, kimsenin açamadığı 6 saatlik yakalamadan daha değerlidir.\n\n### 4) Açıkla (veriyi hikâyeye dönüştür)\n\nTopladıklarınızı basit bir anlatıya çevirin:\n\n- Ne değişti? (yeni build, politika, sürücü, yük)\n- Sistem şimdi ne yapıyor? (yeniden denemeler, çekişme, bloke I/O, zaman aşmaları)\n- Muhtemel neden? (1–2 hipotez, önceliklendirilmiş)

Basitçe açıklayamıyorsanız muhtemelen daha temiz bir yakalama veya daha dar bir hipoteze ihtiyacınız vardır.\n\n### 5) Düzelt, doğrula ve bir sonraki sefer MTTR’yi azalt\n\nEn küçük güvenli düzeltmeyi uygulayın, sonra aynı yeniden üretme adımlarıyla doğrulayın ve “önce vs sonra” yakalamalarıyla teyit edin.\n\nMTTR’yi azaltmak için oyun kitaplarını standardize edin ve sıkıcı işleri otomatikleştirin:\n\n- Bir iz başlatma komutu, bir durdurma ve zipleme komutu\n- Tutarlı klasör yapısı ve adlandırma standardı\n- Belirti başına (çökme vs takılma vs yavaşlama) ne toplanacağına dair kontrol listesi\n\n### Olay sonrası öğrenme: eksik sinyali ekle\n\nÇözülden sonra sorun: “Hangi sinyal bunu daha önce açık ederdi?” diye sorun. O sinyali ekleyin—Sysmon olayını, ETW sağlayıcısını, bir performans sayacını veya hafif bir sağlık denetimini—böylece bir sonraki olay daha kısa ve sakin olur.\n\n## Kalıcı Hale Getirmek: Daha Güvenli Düzeltmeler ve Uzun Vadeli Güvenilirlik\n\nWindows iç işleyişi çalışmasının amacı debugging’i kazanmak değil—gördüklerinizi tekrar etmeyecek değişikliklere dönüştürmektir.\n\n### Bulguları somut aksiyonlara dönüştürün\n\nInternals araçları genellikle problemi küçük bir çubuk setine daraltır. Çeviriyi açık tutun:\n\n- Konfigürasyon değişikliği: bir servis hesabı izni, kayıt değeri, pool boyutu, zamanlanmış görev aralığı.\n- Yama: OS toplu güncellemesi, .NET güncellemesi veya çağrı yığını/sürücü sürümüyle eşleşen satıcı düzeltmesi.\n- Sürücü güncellemesi (veya geri alma): Procmon/ETW sürücü etrafında duraksamalar gösteriyorsa sürücü sürümlerini birinci sınıf bağımlılık olarak ele alın.\n- Geri alma: düzeltme riskliyse hızlı geri dönüş planlayın (bilinen iyi paket, önceki GPO, eski sürücü paketi).\n\n“Çünkü X’i değiştirdik: Procmon/ETW/dökümlerde Y gördüğümüz için” cümlesini yazın. Bu, yerel bilgilerin zamanla bozulmasını engeller.\n\n### Güvenlik önlemleri: değişiklik pencereleri, doğrulama, geri alma\n\nDeğişiklik sürecinizi patlama alanına göre eşleştirin:\n\n- Mümkünse değişiklik penceresi ile daha düşük trafik zamanında uygulayın.\n- Doğrulama adımları tanımlayın (hangi sayaçlar, olay ID’leri veya kullanıcı yollarının iyileşmesi gerekir).\n- Sahibi ve süre sınırı olan net bir geri alma planı hazırlayın ("Hatalar 15 dakikada düşmezse geri al").\n\n### Tekrar uygulanabilir güvenilirlik kalıpları\n\nKök neden spesifik olsa bile, dayanıklılık genellikle tekrar kullanılabilir kalıplardan gelir:\n\n- İş parçacığı açlığı ve takılan bağımlılık zincirlerini önlemek için zaman aşımı’lar.\n- Yeniden deneme fırtınalarını durdurmak için oran sınırlama/backoff.\n- Beklenen geçici hatalar için servis kurtarma seçenekleri (yeniden başlatma eylemleri, hata sıfırlama periyodu).\n- Sadece çökme değil takılmaları da tespit eden sağlık kontrolleri.\n\n### Yakalamalar ve telemetri için veri hijyeni\n\nİhtiyacınız olanı saklayın ve saklamamanız gerekeni koruyun.

Procmon filtrelerini şüpheli süreçlerle sınırlayın, paylaşırken yollar/kullanıcı adlarını temizleyin, ETW/Sysmon verileri için saklama ayarları yapın ve gerekmedikçe yük ağırlıklı ağ yakalamalardan kaçının.\n\n### Oyun kitaplarını operasyonelleştirmek (Koder.ai burada yardımcı olabilir)\n\nTekrarlanabilir bir iş akışınız olduğunda, sonraki adım bunu paketlemek ve başkalarının tutarlı şekilde çalıştırabilmesini sağlamaktır. Bu noktada sohbet tabanlı ajan mimarisiyle uygulama oluşturmayı sağlayan Koder.ai gibi bir platform fayda sağlayabilir: olay kontrol listenizi küçük bir iç uygulamaya (React UI, Go backend, PostgreSQL) dönüştürebilir, müdahalecilere “gözlemle → yakala → açıkla” adımlarında rehberlik eden butonlar ekleyebilir, zaman damgası ve vaka dosyası yapısını standardize edebilir ve yeniden kullanılabilir Procmon filtre şablonları, ETW başlat/durdur düğmeleri ya da dışa aktarılabilir çalışma kitabı üreteci ekleyebilirsiniz. \nKoder.ai sohbet aracılığıyla uygulamalar inşa etmeyi desteklediği için ekipler hızlı iterasyon yapabilir—"ETW oturumu başlat" butonu, Procmon filtre kitaplığı, anlık fotoğraf/geri al özelliği veya dışa aktarılabilir runbook jeneratörü gibi küçük eklentilerle. Koder.ai ayrıca kaynak kodu dışa aktarma ve ücretsizden kurumsala kadar katmanlar sunduğu için küçük başlayıp yönetişimi ölçeklendirmek mümkündür.\n\n### Küçük haftalık pratik planı\n\nHaftada bir bir araç seçin ve 15 dakikalık egzersiz yapın: Procmon ile yavaş uygulama başlangıcını izleyin, Process Explorer’da bir servis ağacını inceleyin, Sysmon olay hacmini gözden geçirin veya bir çökme dökümünü alıp başarısız modülü tanımlayın. Küçük tekrarlar, gerçek olaylarda iş hafızasını güçlendirir ve müdahaleleri daha hızlı—ve daha güvenli—yapar.