Анализ дампа WinDBG без символов - PullRequest
2 голосов
/ 15 июля 2009

У нас произошел инцидент, в ходе которого я позвонил в службу поддержки Microsoft, и они смогли использовать WinDBG для анализа одного из моих мини-дампов и выявления точной проблемы. Я WinDBG проанализировал тот же дамп и не смог пройти мимо стека трассировки. Я предполагаю, что не могу найти золотой самородок, потому что я в неведении, но Microsoft не скажет мне, что они сделали, чтобы раскопать его сами. Есть ли шанс, что я могу получить некоторую помощь по этим сложным вопросам?

Ситуация включала вызов .NET 1.1 в предоставляемый поставщиком веб-сервис. В течение 1 часа в сутки в течение нескольких недель мы не могли пройти проверку подлинности в отношении службы, но соединение не было прервано. Во время каждого отключения мы зависали десятки потоков, пока сервис не вернулся в онлайн.

Если я DebugDiag и Report, я вижу, что поток 49 завис, и запускаю! Clrstack против этого потока.

0:049> !clrstack<br> succeeded<br> Loaded Son of Strike data table version 5 from "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorsvr.dll"<br> Thread 49<br> ESP EIP<br> 1382ec64 7c82860c [FRAME: NDirectMethodFrameStandalone] [DEFAULT] I4 System.Net.UnsafeNclNativeMethods/OSSOCK.recv(I,I,I4,ValueClass System.Net.Sockets.SocketFlags)<br> 1382ec78 10fb1fef [DEFAULT] [hasThis] I4 System.Net.Sockets.Socket.Receive(SZArray UI1,I4,I4,ValueClass System.Net.Sockets.SocketFlags)<br> 1382ecb8 10fb1e65 [DEFAULT] [hasThis] I4 System.Net.Sockets.NetworkStream.Read(SZArray UI1,I4,I4)<br> 1382ece4 10fb1dd1 [DEFAULT] [hasThis] I4 System.Net.TlsStream.ForceRead(SZArray UI1,I4,I4)<br> 1382ed00 10fb1cc4 [DEFAULT] [hasThis] SZArray UI1 System.Net.TlsStream.ReadFullRecord(SZArray UI1,I4)<br> 1382ed20 10a6f7df [DEFAULT] [hasThis] Class System.Exception System.Net.TlsStream.Handshake(Class System.Net.ProtocolToken)<br> 1382ed44 10a6f59b [DEFAULT] [hasThis] Void System.Net.TlsStream..ctor(String,Class System.Net.Sockets.Socket,Boolean,Class System.Security.Cryptography.X509Certificates.X509CertificateCollection)<br> 1382ed5c 10a6f4d0 [DEFAULT] [hasThis] ValueClass System.Net.WebExceptionStatus System.Net.Connection.ConstructTlsChannel(String,Class System.Net.HttpWebRequest,ByRef Class System.Net.Sockets.NetworkStream,Class System.Net.Sockets.Socket)<br> 1382ed78 10a6f47b [DEFAULT] [hasThis] ValueClass System.Net.WebExceptionStatus System.Net.Connection.ConstructTransport(Class System.Net.Sockets.Socket,ByRef Class System.Net.Sockets.NetworkStream,Class System.Net.HttpWebRequest)<br> 1382edac 10a693d7 [DEFAULT] [hasThis] Void System.Net.Connection.StartConnectionCallback(Object,Boolean)<br> 1382f028 791b7f92 [FRAME: ContextTransitionFrame]

(! Clrstack -p не работает для меня. Он возвращает ту же информацию, что и не запрашивать параметры. Я предполагаю, что это потому, что у меня нет закрытых символов для кода.! У меня также не работает , хотя! dumpobj делает. Я загрузил sos через ".loadby sos mscorsvr", а не mscorwks, так как я работаю на сервере. Может ли моя загрузка sos каким-то образом быть неправильной?)

В любом случае, Microsoft была достаточно любезна, чтобы рассказать мне о том, что они нашли. Они сказали мне след стека, который они вытащили, и я вытащил тот же самый. (Это круто.) Однако из трассировки стека они извлекли следующую информацию. Как?

- So the above thread is waiting on a socket. The socket details are mentioned below<br> SOCKADDR @ 01285dc0<br> sin_family = 2 (IP)<br> sin_port = 443<br> sin_addr = 206.16.40.219

А потом они сказали мне имя подвешенного объекта, чтобы я мог его сбросить, и я могу.

0:049> !dumpobj 0x09278dbc<br> Name: System.String<br> MethodTable 0x79b946b0<br> EEClass 0x79b949fc<br> Size 140(0x8c) bytes<br> mdToken: 0200000f (c:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll)<br> String: https://www.vendorname.com/services/v2006/Authentication

Как они получили из этой трассировки стека идентификацию этих объектов без закрытых символов? Как администратор, я не могу просто скомпилировать этот код в режиме отладки, и при этом я не буду развертывать код отладки в производство, за исключением крайних случаев. У Microsoft была точно такая же информация, что и у меня, и они нашли ответ, поэтому я предполагаю, что его можно найти, если я смогу просто преодолеть горб невежества.

(За один ответ я добавляю, что в моем пути поиска символов WinDBG написано: SRV*D:\Tools\Debuggers\Symbols*http://msdl.microsoft.com/download/symbols

Спасибо.

Ответы [ 3 ]

5 голосов
/ 15 июля 2009

Полагаю, они сбросили объект сокета, чтобы посмотреть его внутренние поля. Вы можете использовать! Dso для вывода адресов всех объектов стека или! Dumpheap-type System.Net.Sockets.Socket для получения всех объектов Socket в памяти.

Здесь очень помогает знание внутренних объектов. Учитывая исходный код .NET или декомпиляцию, произведенную .NET Reflector , поможет понять внутреннюю часть объекта сокета.

Вывод объекта сокета даст вам адреса памяти полей m_RemoteEndPoint и m_RightEndPoint. Один из них, вероятно, дал им IP-адрес, порт и семью.

1 голос
/ 15 июля 2009

Они, вероятно, имеют локальные копии всех файлов символов.

Вы можете скачать их здесь , поместить их в локальную систему и затем загрузить в отладчик, набрав:

.symfix c: \ YourLocalSymbols

.reload

1 голос
/ 15 июля 2009

Они использовали Сервер символов для получения символов.

...