Título algo lo dice todo. El comando usual de SOS ! Bpmd no hace mucho bien sin un nombre.¿Cómo romper WinDbg de forma anónima?
Algunas ideas que tenía:
- volcado todos los métodos, a continuación, utilizar bpmd md cuando encuentre el MethodDesc correspondiente
- no es práctico en el uso del mundo real, por lo que puedo decir . Incluso si escribí una macro para limitar el volcado a tipos/métodos anónimos, no hay una manera obvia de diferenciarlos.
- uso del reflector para volcar el nombre MSIL
- no ayuda cuando se trata de montajes dinámicos y/o Reflection.Emit. incapacidad de Visual Studio para leer VARs locales dentro de estos escenarios es toda la razón por la que volví a WinDbg en el primer lugar ...
- establecer el punto de interrupción en VS, esperar a que se golpeó, y luego change to Windbg using the noninvasive trick
- intentar desconectarse de VS hace que se cuelgue (junto con la aplicación). Creo que esto se debe al hecho de que el depurador administrado es un "soft" debugger via thread injection en lugar de un depurador "duro" estándar. O tal vez solo sea un error de VS específico de Silverlight (difícilmente sería el primero I've encountered).
- establecer un punto de interrupción en algún otro lugar conocido para llamar al método anónimo, entonces solo paso en su camino
- mi plan de copia de seguridad, aunque yo prefiero no recurrir a él si esto Q & a revela una mejor manera
Nota bene: Hice un descubrimiento accidental que hacía innecesario WinDbg. Si emites programáticamente DebuggableAttribute (http://msdn.microsoft.com/en-us/library/system.diagnostics.debuggableattribute.aspx) durante la creación del ensamblaje dinámico, podrás ver vars locales en Visual Studio bien . –