USB Aygıtı Tanınmadı Hatasının Nedeni

USB Aygıtı Tanınmadı hatasını neden alıyoruz? Rehberimizde bunu adım adım açıklıyoruz.
USB aygıtınızı bilgisayarınıza taktığınızda sisteminiz aygıtı tanımayıp, Unknown Device (Bilinmeyen Aygıt) olarak Aygıt Yöneticisi’nde göründüğünü varsayalım. Bu bağlamda aygıtın donanım kimliği ”USB/UNKNOWN” olarak görünüyor.

İşlemlere başlamadan önce ETW taraması yaparak, tekrar cihazı bilgisayarımıza bağlıyoruz. Ekrana ”Bilinmeyen Aygıt” uyarısı gelene kadar bekliyoruz ve uyarıyı gördüğümüz anda taramayı durduruyoruz. Şimdi tarama ekranını açın ve ekranda neler yazdığına bakın. Eğer mümkün olduğunca daha yakına ulaşmak istiyorsanız tarayıcı dosyalarını indirin. Bununla beraber, ulaşan hataların izini daha iyi sürebilmeniz için birkaç önemli ipucu vereceğim.

Tarayıcının bize çıkardığı detaylara göz atmadan önce, bu listeyi daha iyi anlamamızı sağlayacak birtakım ipuçlarına göz atacağız. Örneğin, USB aygıtımızı bilgisayarımıza bağladığımızda sorunu çıkaran şeyin ne olduğu. Daha önce verdiğimiz rehberimizde bahsettiğimiz, USB aygıtın neden sistem tarafından tanınmadığına ilişkin detaylara göz atalım.

• USB portuna bağlı aygıtın cevap verme süresi zaman aşımına uğramış olabilir.
• USB aygıtınızın adres istemi başarısız olmuş olabilir.
• USB aygıtınız kendisini aygıt tanımlayıcısına tanıtamamış olabilir.
• USB aygıt tanımlayıcınız bozulmuş ya da hasar görmüş olabilir.
• USB aygıtınız yapılandırma aracını geçememiş olabilir.
• Yapılandırma aracınız bozuk ya da hasar görmüş olabilir.

Eğer girdi kayıtlarından sorunun ne olduğunu anlayabilirsek bu sorunları rahatlıkla çözebiliriz. Bu bağlamda yukarıdaki listede bulunan olasılıklar, girdi kayıtlarını okurken işimizi kolaylaştıracak. Benim kullandığım girdi kayıtları .exl uzantılı olarak kaydedildi. Belgeyi görüntülemek için, File -> Open -> Capture kısmına girin ve görüntüleyeceğiniz .exl uzantılı dosyayı seçin. Artık kayıtları okumaya başlayabiliriz.

İlk başta gördüğümüz SystemTrace girdisi, tüm girdinin tamamıyla ilgili genel bilgiler içerir. SystemTrace ile ilgili detaylı bilgiyi numaralar sayesinde öğrenebilirsiniz. Örneğin taramanın başlangıç süresi ve meydana gelen olayları buradan tespit edebilirsiniz.

Aygıtta Meydana Gelen Olaylar

Ekranda 2. olarak görülen olay, aslında ilk gerçekleşen olay. Bu ve bundan sonraki birkaç olay, cihazın USB kontrolcüsü, bağlantı noktaları ve aygıtı bağladığınız USB portuyla ilgili detaylar içerir.

Meydana gelen olayların tamamını ise olay özeti olarak adlandırıyoruz. İlk olayda olduğu gibi, olay özetleri sürücüyle ilgili aktiviteleri içermez. Fakat diğer olaylar ise aygıtın sürücüyle etkileşimi, iç aksamında gelişen olayları ve değişiklikleri de kapsar. Olay özetleri sadece yaşanan olaylar ile ilgili girdileri kaydeder. Bu bağlamda ben aygıtımı bağladığımda tarayıcıyı başlatmadığımdan dolayı, şimdilik olay özetlerini atlayabiliriz.

Peki hangi adımları atlayacağımız nereden bileceğiz? Usbhub ve usbport olaylarının tamamı olay özetlerine ait. Sürücüyle ilgili yaşanan her olay ise Protocol Name isimli sütunda gösterilir. (Yukarıdaki ekran görüntüsünde pencereyi sadece bana gerekli kısmı gösterecek şekilde ayarladım. Diğer kısmı kesilmiş) Eğer usbhub ve usbport ile ilgili herhangi bir şey görmüyorsanız, talimatları izleyerek taramayı tekrar başlatabilirsiniz.

Burada hata yapmak çok kolay olduğundan, özellikle belirttim. Ayrıca pencerede usbport ve usbhub ile ilgili sıralı olaylar gözükmeli. Eğer usbhub ile ilgili olayların tarihleri arasında çok büyük boşluk varsa, muhtemelen bu boşluk olay özetinin bitmesinden kaynaklıdır. Ayrıca aynı durum, usbport için de geçerli.

Olayların Açıklamaları ve Veri Yüklenmesi

Benim girdilerimde, ilk olaydan sonra gerçekleşen özetim ”USB Hub Wait Wake IRP Completed” açıklama sütununda görünüyor. Bu girdi bize olaylarla ilişkin çoğu kaydedilmiş bilgiyi anında sağlıyor. Benim bilgisayarımda bu olay diğerlerine göre daha önemli görünüyor. Kayıtı başlattıktan sonra, cihazımı bağladım. Ardından usb kontrolcüsü ve hub yanıt vermeye başladı. Özellikle neyin aygıta yanıt verdirttiğini öğrenmek üzere olay verilerine bakmamız gerekmekte. Bu bağlamda sağdaki Frame Details panelinde aşağıdaki adımlara benzeyen yazılar ekrana çıkacaktır.

Frame Information ETW olaylarına ilişkin başlık açıklaması (Olayın ID’sinin hata seviyesini içerir. Olay Yükü) verilerin kaydedildiği zamanı içerir. USB’nin özel yapısı yapıya ilişkin bilgiler ve değerleri (Rakamlar, dizeleri ve dizileri) gibi. Eğer “USB Hub Wait Wake IRP Completed” olayından herhangi bir veri açarsam, “fid_USBHUB_Hub” adında ETW yapı ismini buluyorum.

Yapının içerisine göz atmadan önce, ismini parçalara ayırıp daha iyi kavrayalım:

• fid_: Tüm yapıların ön adı denilebilir. Önemli değil.
• USBHUB_: usbhub sürücüsü üzerinden kayıt edildiği anlamına gelir. Bunu da zaten biliyorduk.
• Rest of the string: Yapı verilerinin ismini içeren obje. Bu durumda ”Hub” olarak tanımlama yapabiliriz.

Böylece fid_USBHUB_Hub, USB bağlantı noktalarını tanımlamak adına usbhub adı altında girdileri kayıt ediliyor. Bu Hub yapısı olaylarıyla beraber, veri yükü Hub üzerinden gerçekleşecek ve biz de özel Hub üzerinden yapılacak olan alışverişi tanımlayabileceğiz. Hep beraber Hub yapısını oluşturan elemanlara bakalım. Sizin için Frame Details ekranını daha fazla veri yükü göstermek adına genişlettim.

Hub yapısı  fid_USBHUB_Device ve fid_USBPORT_Device’da olduğu gibi birbirine çok benzer. Bu ekran genel olarak gerçekleşen diğer olayları görüntüler. Bizim için en önemlileriyse aşağıdaki üç yapı:

• idVendor: USB aygıtın üreticisini temsizl eder.
• (VID) idProduct: Ürünün ismini görüntüler (PID)
• PortPath: USB’yi çalıştırdığınızda kullandığınız bağlantı noktasını (Hub) gösterir. Örneğin:

[0, 0, 0, 0, 0, 0] – Bu durum kök bağlantı dizinini gösterir. (Bilgisayardaki USB Hub kontrolcüsü tarafından kontrol edilen bağlantı girişleri.)

[3, 0, 0, 0, 0, 0] – Bunun anlamı, aygıtın 3 numaralı Hub kök dizinine bağlanmış olduğunu gösteriyor.

[3, 1, 0, 0, 0, 0] – Hub’un 3 numaralı kök Hub dizinine bağlı. Bu olay, aygıtın ya da Hub’un 1 numaralı dahili Hub girişine bağlandığını gösterir.

Bu bağlamda aygıtın kullanabileceği yolları izlemek iyi bir fikir. Cihaz bağlandığında, bilinmeyen VID ve PID değerleri 0 olarak kaydedilir. Bazı aygıtlarda ise VID ve PID hiç görüntülenmeyebilir. Normalde bu bilgiler, aygıt Hub’a bağlandığı anda gönderilir. Artık Hub yolları hakkında da bilgiye sahip olduğumuza göre, cihazımızın verdiği tepkiye ilişkin analizimize başlayabiliriz. Bu işlem bize daha önce öğrendiğimiz gibi kök hub’un port yollarını altı adet sıfır ile gösterecek. Bu bağlamda USB aygıtımı kök Hub’a bağladım ve bağlantı noktasının tepki vermesini bekledim.

Önemli Olayları Elde Etmek

Eğer zamanınız varsa, olayların kronolojik gelişimini tamamen okuyabilirsiniz. Fakat bu bağlamda bizim için önemli olan açıklamayı yakalayamamamız oldukça olası. Bu yüzden Bilinmeyen Aygıt’taki sorunu daha hızlı bulmak için sorunu içeren olayı bulalım. Netmon’ın filtre özelliğiyle bunu kolaylıkla yapabiliriz. Programla beraber gelen en son sürüm filtreyi kullanacağız.

Filter -> Display Filter -> Load Filter -> Standard Filters -> USB -> USB Hub Errors, ve daha sonra Display Filter ekranındaki Apply’e tıklayın. Filtrenin anlamıysa:

Filtreyi açtığımızda birçok olay gösterilecektir.

Ben, tüm hatalara göz atmayı seçtim. Fakat çoğu hatalar CreateDeviceFailure içerisindeki fid_DebugText’ten kaynaklanıyor. Açıkçası hangi sorunun bizim için ciddi olduğunu öğrenmek kolay değil. Fakat hata ayıklama metninin bize verdiği ipucu, yeni cihazımızla ilgili bir işlemin başarısız olduğu. Bu bağlamda gereğinden fazla “Create Device Failed” olayı var görünüyor. Diğer iki istisnai durum ise “CreateDeviceFailure_Popup” ve “GenErr_UserIoctlFailed”. Popup ile ilgili olan olay, çoğu kullanıcıya kendilerinden kaynaklı bir problem gibi gelebilir. Fakat bu hataların tamamı Bilinmeyen Aygıt’ımız ile ilgili olabilir.

Statü Kodları

Birçok olayın nedenleri ve ne olabilecekleri konusunda fazla derine inmedim. Fakat bu hataların da sahip oldukları kodlar bize sorunu anlamamızda yardımcı olabilir. Eğer olay durumunun ismi “NtStatus” bu şekilde ise, bu hatayı yorumlamak için NTSTATUS value table‘ı kullanabilirsiniz. Eğer ismi URB şeklindeyse, bu durumda usb.h içerisindeki USBD_STATUS değerine bakın. Bunu Windows Driver Kit‘teki inc/api içerisinde bulabilirsiniz. Ayrıca hataları daha iyi anlamak için USBD_STATUS name table‘ı da kullanabilirsiniz fakat hata kodlarını içermez.

Geriye Doğru Okuma

Ayrıca hatalara yol açan önemli küçük ayrıntıları da bulabiliriz. Olaylar içerisinden bir önceki hataya bakarak, bu bağlamda Bilinmeyen Aygıt’ımızın kök dizinine ulaşabiliriz. Şimdi önceki istisnai durumlarımızdan ikincisi olan “CreateDeviceFailure_Popup”a göz atalım. Filtre hala aktif durumdayken, bu olayı seçelim ve ”Remove”a tıklayalım. Filtre tekrar onaylamanızı isteyen bir mesaj görüntüleyecek. Daha sonra ise tüm olaylar görünür olacak.

Bu olaylardan önceki iki olay, USB kontrol transferiyle ilgili. fid_USBPORT_Device’ın port yolu değeri her iki olay için de sıfır. Bunun anlamıysa transferin hedefi kök Hub. fid_USBPORT_URB_CONTROL_TRANSFER içerisindeki yapı tamamlama olayının durumu 0 (USBD_STATUS_SUCCESS) ise transfer başarıyla gerçekleşmiş demek. Şimdi gerideki olaylara bakmaya devam edelim.

Geriye doğru baktığımızda önümüzdeki iki olayda ”Create Device Failed”ı görüyoruz. 4. ve sonuncu olay da “CreateDeviceFailure” bu iki istisnai duruma zaten bakmıştık.

Bir olay daha geriye baktığımızda  “Endpoint Close”u görüyoruz. Bunun anlamı, bitiş noktasının artık kullanılabilir olmadığı. Olayın verisi, bu aygıtı ve aygıtın bitiş noktasını açıklar. Bu bağlamda aygıt port yolu [1, 0, 0, 0, 0, 0] şeklinde. Ben daha önce aygıtımı bağladığım ana kontrol noktasının girdi kayıtlarını almıştım. Bunun dışındaki herhangi bir bağlantı noktası konumuz dışarısında kalıyor.  Yani bitiş noktası bağladığım aygıtla alakalı olmalı. Bu bağlamda aygıtın yol numarsı ”1”. Daha önce de karşılaştığımız gibi, sürücü muhtemelen aygıtın bitiş noktasını ulaşılamaz kılıyor. Gerideki olaylara bakmaya devam edelim.

Bir sonraki olay ise USB kontrol transferinin tamamlandığıyla ilgili. İçerisine baktığımızda, transfer için hedeflenen aygıt, (Yol numarası 1 idi.) yani fid_USBPORT_Endpoint_Descriptor yapısı bize bitiş noktasının 0 olarak adreslenmiş olduğunu gösteriyor. Bu, USB aygıtların kontrolü için varsayılan ayar. URB statüsü değeri 0 olduğundan beri 0xC0000004 şeklinde ve bu bağlamda transfer muhtemelen başarısız. Yukarıda da belirttiğimiz gibi USBD_STATUS hakkında daha fazla bilgi için usb.h ve MSDN’e göz atıyoruz.

#define USBD_STATUS_STALL_PID ((USBD_STATUS)0xC0000004L)
Anlamı: “Aygıt paket tanımlayıcısını tekrar durdurdu.”

Neden istek bitiş noktasında durdu? Aynı olaydaki diğer girdilere bakalım, bu bağlamda bu isteğin standart bir aygıt kontrol isteği olduğunu görüyoruz. Ayrıştırıcı paket, bunun standart bir istek olduğunu farkediyor. Daha önce de dediğimiz buradan 3. ve 4. adımlar sayesinde ayrıştırıcı paketini güncelleyin.

İşte ayrılmış istek:

Frame: Number = 184, Captured Frame Length = 252, MediaType = NetEvent
+ NetEvent:
– MicrosoftWindowsUSBUSBPORT: Complete Internal URB_FUNCTION_CONTROL_TRANSFER
– USBPORT_ETW_EVENT_COMPLETE_INTERNAL_URB_FUNCTION_CONTROL_TRANSFER: Complete Internal URB_FUNCTION_CONTROL_TRANSFER
+ fid_USBPORT_HC:
+ fid_USBPORT_Device:
+ fid_USBPORT_Endpoint:
+ fid_USBPORT_Endpoint_Descriptor:
+ fid_URB_Ptr: 0x84539008
– ControlTransfer:
+ Urb: Status = 0xc0000004, Flags 0x3, Length = 0
– SetupPacket: GET_DESCRIPTOR
+ bmRequestType: (Standard request) 0x80
bRequest: (6) GET_DESCRIPTOR 
Value_DescriptorIndex: 0 (0x0)
Value_DescriptorType: (1) DEVICE 
_wIndex: 0 (0x0)
wLength: 64 (0x40)

GET_DESCRIPTOR ve DEVICE’ı birlikte ele alırsa, bu isteğin anlamı “Get device descriptor” oluyor.

Aygıtın normalde USB istemcisine aygıt açıklayıcısı ile cevap vermesi gerekiyor. Fakat bunun yerine aygıt isteğe karşılık vermeyi kesiyor. Bu nedenle sayıma cevap veremediğinden işlem başarısız oluyor. Her ne yaparsak yapalım aygıt, açıklayıcının isteğine cevap vermeyip işlemi durduruyor. Geriye kalan tek şey ise bozuk aygıtı değiştirmek.