2011-09-05 12 views
8

Tengo una aplicación WinForm de C# (.NET 4.0) que se comunica continuamente a una aplicación basada en Linux, recibe algunos datos de ella pocas veces por segundo. He estado ajustando esta aplicación WinForm para reducir su alto uso de CPU cuando vi 'clr.sll! StrongNameSignatureVerification' consume mucha CPU para esta aplicación. Usé Process Explorer para descubrirlo. Algunas búsquedas en Google me dijeron que 'clr.sll! StrongNameSignatureVerification' se está instalando porque CLR está tratando de verificar si se trata de un ensamblado con un nombre fuerte (que no quiero que CLR lo haga).clr.sll! StrongNameSignatureVerification Consumo de CPU

Después de mi investigación adicional sobre esto, probé sn.exe de Microsoft SDK para saltear la verificación de firma para esta aplicación WinForm. Recibí un error al decir que este no es un ensamblaje muy nombrado. No me sorprendió ya que no he firmado esta aplicación o no recuerdo configurar nada que debería invocar CLR para verificar la firma de esta aplicación.

Mi experiencia en la seguridad de las aplicaciones .net es casi nula, así que en este momento estoy buscando ayuda sobre este tema. Cualquier puntero será útil.

Gracias de antemano.

+0

¿Qué ha estado utilizando para perfilar su aplicación? – Iridium

+0

ANTS Profiler de RedGate – silverspoon

+1

Creo que va a necesitar agregar más detalles, p. una pila de llamadas completa que muestra de dónde se está llamando a esta función StrongNameSignatureVerification. Además, ¿cuántas veces se llama a la función? Obviamente, si se tarda 2 segundos en llamar a este método, pero solo ocurre una vez, puede mostrarse como un punto de acceso en su generador de perfiles, pero a largo plazo no afectará significativamente el rendimiento. (Por supuesto, si se llama cientos de veces por segundo, eso es otro asunto). – Iridium

Respuesta

2

Mira el desplazamiento después de clr.sll! StrongNameSignatureVerification, si es más grande que unos pocos miles de bytes, probablemente significa que los símbolos no se cargan en el explorador de procesos y el problema podría estar en cualquier otro método en el CLR. dll.

Cuestiones relacionadas