Access Violation Exception when running JSX handler in Visual Studio debugging session

[paulirwin]

Please note that this is not a consistently reproducible issue AFAICT.

Occasionally, and this seems to be about on average once an hour or so during active development, when going through this process (my normal react.js dev workflow) it results in a catastrophic Access Violation Exception:

1. Start the Visual Studio 2013 debugger for my ASP.NET MVC project that uses React.NET.
2. Make some changes to my JSX file in Sublime. Hit Save.
3. Go over to Chrome, hit refresh. This requests the JSX file from the React.NET JSX handler again.
4. If successful, the JSX handler will return the compiled JS, then I'll test it and probably go back to step 2 again, keeping the same debugger session active. But occasionally here I'll get Visual Studio popping up saying that the "Unknown Handler" had an Access Violation Exception. After clicking OK, the process crashes, and Visual Studio stops debugging.
5. After a crash like this, without modifying the JSX file, I'll re-start the debugging session in VS, call the .jsx URL again executing the handler, and it will compile the JS just fine (meaning there's nothing wrong with the JSX itself).

Due to the obscure nature of the exception, that it says "Unknown Handler", and that I have no call stack or target site, I can't give any further information about the exception itself. I assume it is occurring in the MSIE integration layer, but that is just a guess. I also have yet to deploy this app to any kind of production environment, so this is at least a developer environment / IIS Express issue. I can not confirm if this does or does not happen using full IIS.

While I can't do anything explicitly to reproduce this, I can say that this happens at least under this criteria:

• Keeping the Visual Studio debugging session active across multiple JSX file changes
• This exception has not yet occurred on the first load -- it has always been after I've saved the JSX file a couple times and reloaded the page/called the JSX handler again a few times.
• If it matters, I am not editing the file in Visual Studio (using Sublime 3)

And, if it's relevant (due to the MSIE engine), here's my system info:

• Windows 8.1 update
• IE 11.0.9600.17126

If you would like me to try anything explicitly on my machine to try to reproduce this issue, let me know and I'd be happy to help. Also, I'm interested to know if anyone else has encountered this issue.

[Daniel15]

Are you on React.Core 1.0 or 1.0.1? If only on 1.0, can you please try upgrading to 1.0.1 and see if the same issue occurs? NuGet seems to like only installing 1.0 even though 1.0.1 is available.

[paulirwin]

Ah ha, very strange. It did install 1.0.0 along with older versions of the dependencies even though I only installed it a few days ago, well after 1.0.1 came out, like you said. I will upgrade React.Core to 1.0.1, as well as the latest versions of JavaScriptEngineSwitcher.Jint, JavaScriptEngineSwitcher.Msie, and MsieJavaScriptEngine, and I'll post back here and let you know if it occurs again, or if it seems to be resolved after enough time testing it, I'll post that as well. Thanks for responding so quickly!

[Daniel15]

I just modified the NuGet package to hide 1.0, hopefully that means NuGet will install 1.0.1 (but I don't have access to a Windows machine at the moment so can't test it).

Let me know if upgrading JavaScriptEngineSwitcher.Msie or MsieJavaScriptEngine fixes it, in which case I'll bump the version number requirement. I have a feeling it's in the MSIE engine somewhere. I've been meaning to try V8 on Windows but I had a lot of issues getting the version required by VroomJS to compile on Windows (works fine on Linux though, I use it in production on a pretty simple page with no issues).

Do you have any debug info at all, even a single stack frame?

[paulirwin]

I just encountered the AccessViolationException again on the latest versions of all the NuGet packages. No debug info, no call stack, nothing. I agree that it is most likely in the IE engine. I guess I could try Jint and see if that helps?

[paulirwin]

I still haven't switched over to Jint yet so this is still MSIE, and I just got it again. Here's the full message:

An unhandled exception of type 'System.AccessViolationException' occurred in Unknown Module.

Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

And that's all it gives, no ability to see any other details of the exception in VS. During this, VS shows a "Code not running" tab and there's nothing in the call stack window. If I hit Continue (F5), the process shuts down and VS stops debugging.

I'm going to try removing MSIE in the web.config and use Jint and see if it happens again -- I'm guessing it won't since Jint is managed code.

[paulirwin]

I should also note that this was with a completely different application/solution than when I was getting it before, with completely different, unrelated JSX files, so it doesn't seem to be anything related to my project.

[Daniel15]

I'm having trouble replicating this on my system (Windows 8.1 64-bit, IE 11.0.9600.16521 running in VMWare Fusion). Are you on 64-bit or 32-bit? Can you replicate this issue if you build from source (instructions here) and run the included "React.Samples.Mvc4"?

Switching to Jint in the web.config won't actually work as I'm not using the JS switcher config. ReactJS.NET has its own config. Unfortunately Jint doesn't support JSX compilation at all since the stack gets too large for it to handle :(

[paulirwin]

64-bit, IE 11 on 8.1. I'll try building from source and running the samples, but I'll have to modify the samples to really test it out, as it almost never occurs on the first hit in the app, it's usually after modifying the JSX files multiple times while debugging.

Looking at the "has its own config" link to the source above, I see that you're using ChakraActiveScript. Have you tried it with ChakraJsRt mode? Just curious to know if there's a difference.

[paulirwin]

FYI - My colleague has now also received this exception on his machine, which is also 8.1 with IE 11. So this is not an isolated issue to my machine.

[Daniel15]

I did try ChakraJsRt initially but it failed since it couldn't handle the large Esprima stacks (JSXTransformer uses Esprima for parsing) so I had to stop using it. Could you please send through a small project that replicates the issue? I'm about to go on vacation but I can take a look once I'm back. Thanks!

[jlchmura]

I have the same issue happening, though my debugger is not attached at the time, but I am building in Debug mode.

VS2013 using iisexpress
64-bit Win7
Chrome

I'll make some changes to a JSX inside VS and save. When reloading the page in Chrome, IISExpress crashes with an access violation exception. It doesn't happen every time. Some times I can go 10 or more saves without crash, while other times I'll get two in a row.

[paulirwin]

Thanks @jlchmura, glad it's not just us! Also, an update, I have confirmed that our entire dev team gets this exception regularly. Hopefully someone can figure out what's happening!

[Daniel15]

It's interesting that I haven't been able to repro this :(

I'm using a virtual machine though (in VMWare Fusion). Maybe I should try it on a 'real' machine and see if I get the same error.

[jlchmura]

Another interesting bit of information:

I created a Debug build of the React.NET libraries (just pulled the source this morning) and switched my project to use those. IIS crashes have stopped. Did a Release build and they are back.