excepciones - throw exception c#
C#WebBrowser Control System.AccessViolationException (8)
Tengo un programa que usa el control incorporado en el navegador web. En algún momento durante el uso de esto, no estoy seguro de en qué punto, pero parece ser aleatorio, me aparece el siguiente error:
System.AccessViolationException
FullText = System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32 dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.Run(Form mainForm)
¿Alguien tiene alguna pista sobre por qué podría obtener esto y cómo prevenirlo?
¿Están las páginas que está navegando para alojar cualquier control ActiveX? Si es así, uno de esos puede tener fallas. También revise sus páginas en IE. Vea si se bloquean de la misma manera. Eso ayudará a aislar si es específico para el contenido o el control del navegador.
Encontré esta excepción en varias ocasiones al intentar acceder a WebBrowser.ReadyState y WebBrowser.Document.
Tenía las excepciones exclusivamente en Windows XP 32 bits. Después de que las otras soluciones no ayudaron, parecía ser un problema de enhebrado. Rodeé todos los bloques de código que accedían al control del navegador web con bloqueos mutex, y eso parecía resolver el problema.
Estamos golpeando esto también. Inconsistentemente, obtendremos esta excepción.
Algunas preguntas para ayudar a reducir esto: ¿está utilizando alguna interfaz mshtml directamente (por ejemplo, mshtml.dll)? ¿Haces alguna interferencia COM directamente?
Hemos encontrado que llamar a algunas de las interfaces COM MSHTML incorrectamente puede causar esto.
También descubrimos que hacer un ordenamiento COM incorrectamente puede causar esto.
Si hay un error en la importación de la interfaz MSHTML que utiliza el WebBrowser incorporado, puede causar esto.
Acceder a documentos IFRAME Elementos de otro dominio puede causar esto.
Es posible que hacer llamadas a WebBrowser cuando el documento no está listo también pueda causar esto.
Esto parece ser un problema de Vista, lo que me sucedió fue que mi C # webBrowser1 abría una página web que ejecutaba un applet java que abría una página web externa de IE que ejecuta una aplicación / script ActiveX.
Cuando la secuencia de comandos ActiveX intenta volver a actualizar a la memoria de la aplicación C #, DEP "Prevención de ejecución de datos" en Vista señala esta operación como hostil / virus y finaliza el programa con System.AccessViolationException: Intentó leer o escribir en la memoria protegida. Esto a menudo es una indicación de que otra memoria está corrupta ".
Mi solución para esto fue convertir DEP en Vista con esta línea en cmd
"bcdedit.exe /set {current} nx AlwaysOff"
y reinicia la máquina.
XP también ejecuta DEP, por lo que en ciertos casos supongo que también pasará este frío. Para probar si es un problema DEP hacer esto.
Haga clic derecho en "Mi PC" Seleccione "Propiedades" y "Avanzado" En "Inicio y recuperación, haga clic en Configuración Ahora haga clic en" Editar "El bloc de notas acaba de comenzar. Simplemente reemplace la línea: Código: no ejecutar opción por AlwaysOff Reinicie su PC a complete la transacción
Si desea reactivar el DEP, sea suficiente para realizar el reverso, así:
Reemplazar por Cita: AlwaysOff noexecute = noexecute = optin
Mi intuición es que estás tratando de manipular el documento antes de que hayas navegado hacia uno. Intente navegar a "about: blank" antes de cambiar el texto del documento o html.
Si ya está realizando la navegación, tenga en cuenta que la navegación es asincrónica, por lo que debe controlar los eventos del navegador para detectar cuándo se completa la navegación. De lo contrario, puede intentar escribir en el documento antes de que exista.
Recientemente hemos tenido un problema similar en máquinas de varios clientes. El problema resultó ser un error en el control de MSHTML en ciertos entornos. Un síntoma común para el problema parece ser el registro roto de la biblioteca jscript.dll.
Síntomas que pueden ayudar a diagnosticar si se trata del mismo problema: jscript.dll no aparece en Módulos en el depurador y el proceso no lo carga; El seguimiento de pila nativo para el bloqueo es el siguiente:
mshtml!CRootTracker::CollectGarbageInternal+0xd
mshtml!CDoc::ReduceMemoryPressureTask+0x29
mshtml!CStackPtrAry<unsigned long,12>::GetStackSize+0xb6
mshtml!GlobalWndProc+0x183
USER32!InternalCallWinProc+0x23
USER32!UserCallWinProcCheckWow+0x109
USER32!DispatchMessageWorker+0x3bc
USER32!DispatchMessageW+0xf
La solución es volver a registrar la biblioteca jscript.dll y el bloqueo debería desaparecer.
Volver a registrar la biblioteca se realiza de la siguiente manera (ejemplo dado para Windows de 64 bits; de lo contrario, solo es necesaria la primera línea):
C:/Windows/System32/regsvr32.exe C:/Windows/System32/jscript.dll
C:/Windows/SysWOW64/regsvr32.exe C:/Windows/SysWOW64/jscript.dll
Ambos comandos tienen que ser "Ejecutar como administrador".
Solo una sugerencia, no soy experto en esto, pero he usado mucho el WebBrowser en aplicaciones anteriores, pero ¿por qué no escribes una función para esperar 1 segundo antes de intentar pasar el navegador y siempre verificas el estado de antemano también? Podría ralentizarlo un poco, pero debería hacerlo a prueba de balas. :)
Terminé simplemente abriendo la página web en el navegador. De esa forma ni siquiera tengo que preocuparme por esto. Todavía es extraño que arroje este error sin embargo.