31

I have a program that uses the built in webbrowser control. At some point during the usage of this, I'm not sure at what point, but it appears to be random, I get the following 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)

Does anyone have any clues as to why I would get this and how to prevent it?

Aaron Smith
  • 3,332
  • 4
  • 29
  • 25
  • If anyone ever finds a consistent solution for this let me know and I'll accept it. I got around it by opening the browser outside of the application as opposed to the browser control. – Aaron Smith Apr 27 '10 at 00:46
  • 2
    Is there a way to give ownership of a question over to someone else? I no long work on this system, and therefore will NEVER accept an answer here... – Aaron Smith Sep 14 '10 at 19:24

8 Answers8

7

We have recently had a similar problem on the machines of several customers. The problem turned out to be a bug in the MSHTML control in certain environments. A common symptom for the problem seems to be the broken registration of the jscript.dll library.

Symptoms that may help to diagnose if it's the same problem - the jscript.dll is not listed in Modules in the debugger and is not loaded by the process; Native stack trace for the crash is the following:

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

The solution is to re-register the jscript.dll library and the crash should go away.

Re-registering the library is done as follows (example given for 64-bit Windows, otherwise only the first line is necessary):

C:\Windows\System32\regsvr32.exe C:\Windows\System32\jscript.dll
C:\Windows\SysWOW64\regsvr32.exe C:\Windows\SysWOW64\jscript.dll

Both commands have to be "Run as Administrator".

Troll
  • 1,895
  • 3
  • 15
  • 34
Filip Navara
  • 4,818
  • 1
  • 26
  • 37
4

I encountered this exception at various occasions while trying to access WebBrowser.ReadyState and WebBrowser.Document.

I was having the exceptions exclusively on Windows XP 32bit. After the other solutions didn't help, it appeared to be a threading issue. I surrounded any code blocks that accessed the web browser control with mutex locks, and that seemed to solve the problem.

Jacotb
  • 135
  • 1
  • 1
  • 8
  • 2
    After 10 hours of debugging and searching this is what helped me. Thanks! By the way, I was getting exceptions in Windows 7. – Martynas Apr 23 '13 at 13:14
3

My gut feeling is that you are trying to manipulate the document before you've navigated to one. Try navigating to "about:blank" before changing the document text or html.

If you already are performing navigation, note that navigation is asynchronous, so you need to monitor the events of the browser in order to detect when the navigation is complete. Otherwise, you may try to write to the document before it exists.

Jeff Yates
  • 61,417
  • 20
  • 137
  • 189
  • 1
    I'm not writing to the document. I'm just passing a URL to the webbrowser. I also have a back and a refresh button. I'm not manipulating the text or html in the document at any time. – Aaron Smith Oct 07 '08 at 15:25
1

We're hitting this too. Inconsistently, we'll get this exception.

Some questions to help narrow this down: are you using any mshtml interfaces directly (e.g. mshtml.dll)? Doing any COM interop directly?

We've found that calling some of the COM MSHTML interfaces incorrectly can cause this.

We've also found that doing COM marshalling incorrectly can cause this.

If there's a bug in the MSHTML interface import that the built-in WebBrowser uses, it can cause this.

Accessing document IFRAME Elements from another domain can cause this.

It's possible that making WebBrowser calls when the document isn't quite ready may also cause this.

Judah Gabriel Himango
  • 58,906
  • 38
  • 158
  • 212
0

Just a suggestion, I'm no expert on this but have used the WebBrowser a lot in previous applications, but why dont you write a function to wait 1 second before attempting to pass the browser anything and always check the readystate beforehand aswell. Might slow it down a bit but it should make it bullet proof. :)

Kevin Dark
  • 458
  • 5
  • 15
0

This seems to be a Vista Issue, what happend to me was that my C# webBrowser1 opend a web page that runned a java applet that opend a external IE webpage that runs a ActiveX app/script.

When the ActiveX script tryes to update back in to the memory of the C# app the DEP "Data Execution Prevention" in Vista flags this operation as hostile/virus and ends the program with the System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

My fix for this was to turn of DEP in Vista with this line in cmd

"bcdedit.exe /set {current} nx AlwaysOff"

and reboot the machine.

XP also run DEP so in certain cases i guess this cold happen here too. To test if its a DEP issue do this.

Right click on "My Computer" Select "Properties" and "Advanced" Under "Startup and Recovery, click Settings Now click on "Edit" The notepad has just begun. Simply replace the line: Code: noexecute optionn by AlwaysOff Restart your PC to complete the transaction.

If you want to reactivate the DEP be sufficient to conduct the reverse, like this:

Replace by Quote: AlwaysOff noexecute = noexecute = optin

Darkmage
  • 1,583
  • 9
  • 24
  • 42
0

Are the pages you are navigating to hosting any ActiveX controls? If yes, one of those may be flawed. Also check your pages in IE. See if they crash the same way. That will help isolate if it's specific to the content or the browser control.

Bob King
  • 25,372
  • 6
  • 54
  • 66
0

I ended up just opening up the webpage in the browser. That way I don't even have to worry about this. It's still strange that it throws this error though.

Aaron Smith
  • 3,332
  • 4
  • 29
  • 25
  • I originally accepted this, but some people may not be able to use this as an answer, so I'm going to leave this question unanswered for now as long as other people are having issues. – Aaron Smith Jun 12 '09 at 15:35