Windows’ta Process Monitor ile Uygulama İzleme

Yazar:komut.io ekibi Windows Sunucu İzleme ve Performans Yönetimi
0 Yorum

Bir production sunucusunda uygulama aniden yavaşlamaya başladığında ya da tamamen çöktüğünde, elimizdeki en güçlü silahlardan biri Process Monitor’dür. Yıllar içinde onlarca “nedeni bilinmeyen” sorunu bu araçla çözdüm ve şunu söyleyebilirim: Process Monitor’ü gerçekten öğrenmek, Windows sistem yöneticiliğinde bir dönüm noktasıdır.

Process Monitor Nedir ve Neden Bu Kadar Güçlüdür?

Process Monitor (ProcMon), Sysinternals Suite içinde yer alan, Microsoft tarafından sunulan ücretsiz bir gerçek zamanlı izleme aracıdır. Registry erişimlerini, dosya sistemi işlemlerini, ağ aktivitelerini ve process/thread davranışlarını eş zamanlı olarak kayıt altına alır. Windows’un kendi Event Viewer’ı size “bir şey oldu” der, Process Monitor ise “bu process, şu anda, o dosyaya, şu iznini kullanarak erişmeye çalıştı ve şu hatayı aldı” diye anlatır.

Task Manager veya Resource Monitor ile kıyaslandığında Process Monitor çok daha granüler bir görünüm sunar. Task Manager size CPU yüzdesini gösterir; Process Monitor hangi DLL’in yüklenemediğini, hangi registry anahtarının eksik olduğunu, hangi named pipe’ın timeout verdiğini gösterir.

Kurulum ve İlk Başlatma

Sysinternals Suite’i Microsoft’un resmi sayfasından indirmenizi öneririm. Tek tek araç olarak da indirebilirsiniz.

# PowerShell ile Sysinternals Suite'i indirmek için
Invoke-WebRequest -Uri "https://download.sysinternals.com/files/SysinternalsSuite.zip" -OutFile "C:ToolsSysinternalsSuite.zip"
Expand-Archive -Path "C:ToolsSysinternalsSuite.zip" -DestinationPath "C:ToolsSysinternals"

Process Monitor’ü her zaman yönetici olarak çalıştırın. Aksi takdirde kernel-level olayları yakalayamazsınız ve eksik log analizi yaparsınız, bu da sizi yanlış sonuçlara götürür.

# Yönetici PowerShell ile Process Monitor'ü başlatmak
Start-Process -FilePath "C:ToolsSysinternalsProcmon.exe" -Verb RunAs

İlk açtığınızda araç hemen kayıt almaya başlar ve ekran saniyeler içinde dolup taşar. Paniklemeyın; bu normaldir. İlk yapmanız gereken şey Ctrl+E ile kaydı durdurmak ve filtreleri ayarlamaktır.

Filtre Sistemi: Process Monitor’ün Kalbi

Ham veriyle çalışmak neredeyse imkansızdır. Tipik bir Windows sunucusunda saniyede yüzlerce olay gerçekleşir. Filtre sistemi olmadan Process Monitor’ü kullanmak, okyanusta iğne aramak gibidir.

Filtre ekranına Ctrl+L ile ulaşırsınız. Temel filtre mantığı şöyledir:

  • Process Name: Belirli bir process adına göre filtrele
  • Process ID: PID’e göre filtrele, aynı isimde birden fazla process varsa kritik
  • Path: Dosya veya registry yoluna göre filtrele
  • Result: Sonuca göre filtrele, özellikle “ACCESS DENIED” veya “NAME NOT FOUND” için çok kullanışlı
  • Category: Write, Read, Network gibi kategorilere göre filtrele
  • Event Class: Registry, File System, Network, Process/Thread arasında seçim

Gerçek dünya senaryosunda en çok kullandığım filtre kombinasyonu şudur: Process Name ile hedef uygulamayı seçip Result olarak “ACCESS DENIED” filtreliyorum. Bu kombinasyon bana “bu uygulama neye erişemedi” sorusunun cevabını verir.

# Process Monitor'ü komut satırından filtreli başlatmak için PML dosyası kullanabilirsiniz
# Önce filtreleri GUI'den ayarlayıp PMC dosyası olarak kaydedin, sonra:
Start-Process -FilePath "C:ToolsSysinternalsProcmon.exe" -ArgumentList "/LoadConfig C:Configsmyfilter.pmc" -Verb RunAs

Gerçek Dünya Senaryosu 1: IIS Uygulaması Neden Çöküyor?

Geçen yıl bir müşterinin production IIS sunucusunda .NET uygulaması her gece 02:00 ile 04:00 arasında çöküyordu. Event Viewer’da sadece generic bir AppPool crash mesajı vardı. Kimse nedenini bulamıyordu.

Process Monitor’ü devreye aldım. Filtre olarak:

  • Process Name: w3wp.exe (IIS worker process)
  • Result: ACCESS DENIED
  • Event Class: File System

Birkaç dakika içinde sorun ortaya çıktı. Uygulama geceleri bir log rotation işlemi başlatıyor, bu işlem sırasında C:AppLogsarchive klasörüne yazmaya çalışıyor, ancak IIS AppPool kimliğinin (ApplicationPoolIdentity) o klasöre yazma izni yoktu. Klasör bir önceki sistem yöneticisi tarafından elle oluşturulmuş ve izinler hiç ayarlanmamıştı.

# PowerShell ile IIS AppPool kimliğine klasör izni vermek
$acl = Get-Acl "C:AppLogsarchive"
$permission = "IIS AppPoolMyAppPool", "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow"
$accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule($permission)
$acl.SetAccessRule($accessRule)
Set-Acl "C:AppLogsarchive" $acl

Sorun çözüldü. İki haftalık “neden çöküyor?” sorusu, Process Monitor ile 20 dakikada yanıt buldu.

Gerçek Dünya Senaryosu 2: Registry Kaynaklı Uygulama Hatası

Bir ERP uygulaması kurulumdan sonra çalışmıyordu. Hata mesajı jenerikti: “Uygulama başlatılamadı, lütfen yöneticinize başvurun.” Bu tür mesajlar sistem yöneticilerinin kâbusudur.

Process Monitor’de şu filtreyi kurdum:

  • Process Name: erp_client.exe
  • Result: NAME NOT FOUND
  • Event Class: Registry

Kayıt defteri aramalarında uygulama HKLMSOFTWARECompanyNameERPClientLicenseKey yolunu arıyordu ve bulamıyordu. Setup sihirbazı bu anahtarı 32-bit registry’e yazmış, ancak uygulama 64-bit sistemde 64-bit registry yoluna bakıyordu. WOW6432Node meselesiydi.

# Registry anahtarını kontrol etmek ve doğru yere kopyalamak
# 32-bit path: HKLM:SOFTWAREWOW6432NodeCompanyNameERPClient
# 64-bit path: HKLM:SOFTWARECompanyNameERPClient

$sourceKey = "HKLM:SOFTWAREWOW6432NodeCompanyNameERPClient"
$destKey = "HKLM:SOFTWARECompanyNameERPClient"

if (!(Test-Path $destKey)) {
    New-Item -Path $destKey -Force
}

$licenseKey = Get-ItemProperty -Path $sourceKey -Name "LicenseKey"
Set-ItemProperty -Path $destKey -Name "LicenseKey" -Value $licenseKey.LicenseKey
Write-Host "Registry anahtarı başarıyla kopyalandı."

Gelişmiş Özellik: Process Tree ve Stack Trace

Process Monitor’ün az bilinen ama son derece güçlü özelliklerinden biri process tree görünümüdür. Ctrl+T ile açılan bu pencere hangi process’in hangisini başlattığını gösterir. Özellikle malware analizi veya beklenmedik process spawn senaryolarında çok işe yarar.

Stack trace özelliği ise bir olaya çift tıkladığınızda ve “Stack” sekmesine geçtiğinizde ortaya çıkar. Bu size tam call stack’i gösterir; hangi fonksiyon zincirinin bu işlemi tetiklediğini anlayabilirsiniz. Tabii bunun tam çalışması için sembol dosyalarına (PDB) ihtiyaç vardır.

# Microsoft Symbol Server'ı ayarlamak için ortam değişkeni
[System.Environment]::SetEnvironmentVariable("_NT_SYMBOL_PATH", 
    "srv*C:Symbols*https://msdl.microsoft.com/download/symbols", 
    "Machine")

# Process Monitor sembol ayarı Options > Configure Symbols menüsünden yapılır
# Symbol path: srv*C:Symbols*https://msdl.microsoft.com/download/symbols

Otomatik Log Toplama: Headless Mod

Bazen sorunu anlık yakalayamazsınız; bir zamanlama sorunu vardır veya gece yarısı oluşan bir problemi sabah işe gelince analiz etmek istersiniz. Process Monitor’ün headless (GUI olmadan arka planda çalışma) modu bu ihtiyacı karşılar.

# Process Monitor'ü arka planda başlatmak ve belirli süre sonra durdurmak
Start-Process -FilePath "C:ToolsSysinternalsProcmon.exe" `
    -ArgumentList "/Quiet /Minimized /BackingFile C:Logsprocmon_log.pml /LoadConfig C:Configsmyfilter.pmc" `
    -Verb RunAs

# 30 dakika sonra durdurmak için
Start-Sleep -Seconds 1800
Stop-Process -Name "Procmon" -Force
Write-Host "Process Monitor logu kaydedildi: C:Logsprocmon_log.pml"
# Görev Zamanlayıcı ile otomatik başlatmak için
$action = New-ScheduledTaskAction -Execute "C:ToolsSysinternalsProcmon.exe" `
    -Argument "/Quiet /Minimized /BackingFile C:Logsprocmon_$(Get-Date -Format 'yyyyMMdd').pml /LoadConfig C:Configsnightfilter.pmc"

$trigger = New-ScheduledTaskTrigger -Daily -At "01:45AM"

Register-ScheduledTask -Action $action -Trigger $trigger `
    -TaskName "ProcMonNightCapture" -RunLevel Highest `
    -User "SYSTEM" -Force

Write-Host "Gece kaydı için zamanlanmış görev oluşturuldu."

Bu yaklaşımla gece sorunlarını sabah analiz edebilirsiniz. PML dosyasını process monitor ile açtığınızda tüm olaylar filtrelenebilir şekilde karşınızda olur.

Log Analizi ve CSV’e Aktarma

Büyük PML dosyalarını bazen PowerShell veya Excel ile analiz etmek gerekebilir. Process Monitor, logları CSV formatına aktarabilir.

# Komut satırından PML dosyasını CSV'e dönüştürmek
Start-Process -FilePath "C:ToolsSysinternalsProcmon.exe" `
    -ArgumentList "/OpenLog C:Logsprocmon_log.pml /SaveAs C:Logsprocmon_export.csv" `
    -Verb RunAs -Wait

# CSV'i PowerShell ile analiz etmek
$logs = Import-Csv "C:Logsprocmon_export.csv"

# Sadece ACCESS DENIED olaylarını filtrelemek
$accessDenied = $logs | Where-Object { $_.Result -eq "ACCESS DENIED" }
$accessDenied | Select-Object "Time of Day", "Process Name", "Path", "Result" | 
    Format-Table -AutoSize

# En çok hata üreten process'leri bulmak
$logs | Where-Object { $_.Result -like "*DENIED*" -or $_.Result -like "*NOT FOUND*" } |
    Group-Object "Process Name" | 
    Sort-Object Count -Descending | 
    Select-Object -First 10 Name, Count |
    Format-Table -AutoSize

CSV analizi özellikle uzun süreli kayıtlarda altın değerindedir. Binlerce satır arasında manuel gözle bakamayacağınız pattern’leri PowerShell ile saniyeler içinde bulabilirsiniz.

Gerçek Dünya Senaryosu 3: DLL Hell Problemi

Kurumsal bir muhasebe yazılımı, belirli bir Windows güncellemesinden sonra çalışmamaya başladı. Hata aynen şöyleydi: “The application failed to initialize because the side-by-side configuration is incorrect.”

Bu tür hatalar genellikle DLL version uyuşmazlıklarından kaynaklanır ve tanımlaması son derece güçtür. Process Monitor filtresi:

  • Process Name: muhasebe.exe
  • Event Class: File System
  • Path contains: .dll
  • Result: NAME NOT FOUND

Sonuç çok netti. Uygulama C:WindowsWinSxS altında belirli bir Visual C++ runtime DLL’ini arıyor ve bulamıyordu. Windows güncellemesi bu DLL’in versiyonunu değiştirmişti.

# Yüklü VC++ Runtime versiyonlarını kontrol etmek
Get-ItemProperty HKLM:SoftwareWow6432NodeMicrosoftWindowsCurrentVersionUninstall* |
    Where-Object { $_.DisplayName -like "*Visual C++*" } |
    Select-Object DisplayName, DisplayVersion |
    Sort-Object DisplayName

# WinSxS'te aranan DLL'i bulmak
Get-ChildItem -Path "C:WindowsWinSxS" -Filter "msvcr*.dll" -Recurse -ErrorAction SilentlyContinue |
    Select-Object FullName, LastWriteTime |
    Sort-Object LastWriteTime -Descending |
    Select-Object -First 20

Çözüm, uygun Visual C++ Redistributable paketini yeniden yüklemekti. Ama bunu Process Monitor olmadan bulmak saatler alırdı.

Boot-Time Loglama: En Gizli Özellik

Windows başlarken oluşan sorunları yakalamak için Process Monitor’ün en az bilinen özelliği olan boot-time loglama özelliği devreye girer. Bu mod, ProcMon’un bir kernel driver olarak sisteme yüklenmesini ve işletim sistemi başlar başlamaz kayıt almaya başlamasını sağlar.

Etkinleştirmek için: Options menüsünden “Enable Boot Logging” seçilir. Bir sonraki açılışta sistem boot sürecinin tamamı loglanır.

# Boot loglama sonrası oluşan geçici log dosyasını okumak için
# Boot sonrası Process Monitor açıldığında otomatik olarak sorar
# Manuel olarak şu konumdaki dosyayı açabilirsiniz:
$bootLog = "C:ProcMon.pml"
if (Test-Path $bootLog) {
    Write-Host "Boot log bulundu: $bootLog"
    Write-Host "Boyut: $((Get-Item $bootLog).Length / 1MB) MB"
    # Process Monitor ile açmak için:
    Start-Process -FilePath "C:ToolsSysinternalsProcmon.exe" `
        -ArgumentList "/OpenLog $bootLog" -Verb RunAs
} else {
    Write-Host "Boot log bulunamadı. Boot logging etkin olmayabilir."
}

Bu özelliği özellikle servis başlatma sorunlarında, driver çakışmalarında ve antivirüs kaynaklı yavaş boot sorunlarında kullanıyorum. Bir keresinde bir müşterinin sunucusu 8 dakikada başlıyordu, boot log analizi ile antivirüs yazılımının her DLL yüklemesini scan ettiğini ve bunu defalarca yaptığını tespit ettik. Exclusion listesine kritik sistem dizinlerini ekledikten sonra boot süresi 2 dakikaya indi.

Performans İpuçları: Process Monitor Kullanırken Dikkat Edilmesi Gerekenler

Process Monitor yoğun çalıştığında sistemin kendisi de etkilenebilir. Özellikle production sunucularında dikkatli olmak gerekir.

  • Drop Filtered Events: Options menüsünden bu seçeneği aktif edin. Filtrelenmiş olaylar memory’e hiç alınmaz, bu da bellek tüketimini önemli ölçüde azaltır.
  • Backing file kullan: Logları RAM’de değil, doğrudan diske yazmasını sağlayın. File menüsünden “Backing File” ayarı yapılır.
  • Kısa süreli kayıt: Production’da mümkün olduğunca kısa tutun, sorun yoğunluğu varsa 30-60 saniye yeterlidir.
  • Spesifik filtreler: Ne kadar dar filtre kurarsanız, araç o kadar az iş yapar ve sisteme o kadar az yük bindirir.
# Process Monitor'ün CPU kullanımını izlemek
while ($true) {
    $procmon = Get-Process -Name "Procmon" -ErrorAction SilentlyContinue
    if ($procmon) {
        Write-Host "$(Get-Date -Format 'HH:mm:ss') - ProcMon CPU: $($procmon.CPU) | RAM: $([math]::Round($procmon.WorkingSet64/1MB, 2)) MB"
    }
    Start-Sleep -Seconds 5
}

Diğer Sysinternals Araçlarıyla Kombinasyon

Process Monitor tek başına güçlüdür ama bazı araçlarla birlikte kullanıldığında inanılmaz bir tanı seti oluşturur.

  • Process Explorer: PID’leri ve process hiyerarşisini görmek için. Process Monitor’daki bir PID’in hangi uygulamaya ait olduğunu doğrulamak için idealdir.
  • TCPView: Ağ bağlantılarını detaylı görmek için. Process Monitor’de gördüğünüz network olaylarını TCPView ile doğrulayabilirsiniz.
  • AutoRuns: Boot-time loglama ile birlikte kullanıldığında başlangıçta yüklenen her şeyi gösterir.
  • Handle: Bir dosyanın hangi process tarafından açık tutulduğunu bulmak için, özellikle “dosya kullanımda” hatalarında.
# Handle aracı ile belirli bir dosyayı hangi process'in tuttuğunu bulmak
# (Process Monitor'de gördüğünüz bir dosya yolunu araştırmak için)
$targetFile = "C:AppDataimportant.log"
$handleOutput = & "C:ToolsSysinternalshandle.exe" $targetFile 2>&1
Write-Host $handleOutput

Sonuç

Process Monitor, Windows sistem yöneticiliğinin olmazsa olmaz araçlarından biridir. Öğrenme eğrisi vardır, ilk başta aşırı bilgi yığını bunaltıcı gelebilir, ancak filtre sistemini kavradıktan sonra bu araç olmadan nasıl çalıştığınızı sorgulamaya başlarsınız.

Benim tavsiyem şu: Process Monitor’ü kritik sorun anında öğrenmeye çalışmayın. Önce test ortamında, bildiğiniz bir problemi kasıtlı olarak yaratarak pratik yapın. Registry anahtarını silin, bir klasörün iznini kaldırın, yanlış bir DLL kopyalayın ve Process Monitor’ün bu senaryoları nasıl yakaladığını gözlemleyin. Bu pratik sizi gerçek problemlerde çok daha hızlı hareket ettirecektir.

En değerli sistem yöneticileri sorunları hızlı çözenler değil, sorunların kök nedenini bulanlar ve tekrar oluşmasını engelleyenlerdir. Process Monitor sizi tam da bu noktaya taşır.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir