JSX on-the-fly compilation results in AccessViolationException on ASP.NET 5 MVC 6

[beruic]

I get the following exception whenever I try to load a .jsx file:

System.AccessViolationException was unhandled
Message: An unhandled exception of type 'System.AccessViolationException' occurred in MsieJavaScriptEngine.dll
Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

I followed the guide on Getting Started on ASP.NET 5 on a new MVC 6 project.

The really strange thing is that I don't know how I can make the error disappear, but when I do, it won't reappear until I clean the project. Sometimes it's hard to get rid of, other times it's gone after a few tries.

I have even seen it start working without the script being added to the configuration. Right now my config has:

config
    .AddScript("~/lib/react/react.js")
    .AddScript("~/lib/react/react-dom.js")
    .AddScript("~/lib/react/react-dom-server.js")
    .AddScript("~/app/app.jsx");

I know this issue is probably related to #28, but either something is missing from the guide, or something should be fixed.

Update 1:
After looking round further, it seems that MsieJavaScriptEngine.dll is the culprit. I updated my config with .SetAllowMsieEngine(false), and installed JavaScriptEngineSwitcher.V8. Still, I get that the directory bin\Debug\net461\win7-x64\ClearScript.V8 is missing. When I look in bin\Debug\net461\win7-x64\ I see ClearScript.dll, so I don't get why it wants to look in that folder.

Update 2:
I tried adding the folder bin\Debug\net461\win7-x64\ClearScript.V8, but of course this gives another error. How do I get V8 working?

[gaelian]

I'm running into similar problems at the moment.

I'm trying to go through the ReactJS.NET tutorial at the moment. My environment is VS 2015 Community (14.0.25123.00 Update 2), I'm running on ASP.NET Core RC2 (1.0.0-preview1-002702) and ReactJS.NET 2.4.0. I'm using the full .NET CLR ("net461") as I gather ReactJS is not currently compatible with the Core CLR. I've seen this issue and I've also seen this issue.

Working my way through the tutorial, there are some obvious differences that can be easily worked around (e.g. change @Url.Content("~/Scripts/Tutorial.jsx") to point to the actual path of my JSX file within the new wwwroot of my ASP.NET Core site) but there's some less obvious weird stuff going on too. I intermittently get the same error mentioned by @beruic:

System.AccessViolationException was unhandled
Message: An unhandled exception of type 'System.AccessViolationException' occurred in MsieJavaScriptEngine.dll
Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Yesterday, it seemed like it had something to do with which web server setup I use to debug my project. I was consistently getting the System.AccessViolationException when running my project through IIS Express (which I gather reverse proxies over to Kestrel thought I'm not 100% convinced this documentation is up to date), but not when running via Kestrel directly. Then the problem seemed to flip and was only happening when I ran the project through kestrel directly and worked fine when I used IIS Express. Now I can't seem to reproduce it consistently at all unless I move onto the "Optimization: Server-side rendering" section of the ReactJS.NET tutorial. After implementing the steps in this section (noting that App_Start\ReactConfig.cs is assumedly replaced by the relevant section within Startup.cs), I am consistently getting the same System.AccessViolationException. Like @beruic I'm not entirely sure how to get V8 working with ReactJS.NET.

I also note that the way bundling and minification is done in ASP.NET Core has substantially changed from the older ASP.NET method outlined in the ReactJS.NET tutorial, I'm not super familiar with Gulp and what's needed for Gulp to play nicely with JSX (I gather I'll need to hook Babel into the mix somehow), so I haven't been able to get it working as yet. But I do wonder, what will the role of ReactJS.NET be in relation to bundling/minification in the new ASP.NET Core world? Will it have any role?

I know ASP.NET Core is moving quite quickly at the moment, I'm starting to think it might be better to slowly back away from using ReactJS.NET with ASP.NET Core until things stabilise a little and the various documentation can catch up.

[Daniel15]

I've seen this error myself several times, but only when using the MSIE JS Engine. I reported it to the developer of the MSIE JS engine library here: Taritsyn/MsieJavaScriptEngine#7

As for getting ClearScript working, several people have done that with ASP.NET Core in the past, I haven't tried it myself recently though. Here's an example where @samppis got ASP.NET 5 + ReactJS.NET + ClearScript running on Azure: #198 along with his blog post at http://www.samulihaverinen.com/web-development/dotnet/2016/01/19/how-to-run-clearscript-v8-javascript-engine-in-azure/ and the documentation he wrote at http://reactjs.net/guides/azure.html

That was around either Beta 8 or RC1 though. If I get some free time, I'll see if anything has changed with RC2 that would cause this to break.

[beruic]

Thank you!
As far as I have read, there are significant changes of support in RC2. I hope you can fix this, as I don't have the time or expertise to do it, and my project would really benefit from server side rendering.

[brentarias]

I have the same setup as @gaelian (same IDE version, same NuGet package versions, same ASP.NET Core RC2 on full-clr, etc.). I am having the same issue, though I am running on Kestrel.

My startup.cs has this:

        app.UseReact((options) =>
        {
            options.AddScriptWithoutTransform("~/bundle.js");
        });

I can make the error disappear if I comment the AddScriptWithoutTransform invocation, then clean and rebuild the application. At that point my JSX transform that produces "Hello World! I am a CommentBox" - per the React.Net tutorial - works fine.

Every time I put the AddScriptWithouTransform back in, the MsieJavaScriptEngine.dll access violation error comes back.

[Daniel15]

Hey thanks @brentarias, that's a good lead. Maybe something in the JavaScript engine initialisation is causing the error... Perhaps a race condition or something.

[ghotiphud]

Seeing this issue with React.MSBuild consistently as well. I have an application with only a handful of jsx files, but I noticed a definite uptick in the occurrence of the exception as I added more jsx files. Hopefully this tidbit helps.

Edit: Running .Net 4.5.2, Win 7, building a Sharepoint Add-in, so MVC & CoreCLR are not involved.

Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
     at MsieJavaScriptEngine.JsRt.Ie.IeNativeMethods.JsCallFunction(IeJsValue function, IeJsValue[] arguments, UInt16 argumentCount, IeJsValue& result)
     at MsieJavaScriptEngine.JsRt.Ie.IeJsValue.CallFunction(IeJsValue[] arguments)
     at MsieJavaScriptEngine.JsRt.Ie.ChakraIeJsRtJsEngine.<>c__DisplayClassc.<CallFunction>b__b()
     at MsieJavaScriptEngine.JsRt.Ie.ChakraIeJsRtJsEngine.InvokeScript[T](Func`1 func)
     at MsieJavaScriptEngine.JsRt.Ie.ChakraIeJsRtJsEngine.CallFunction(String functionName, Object[] args)
     at MsieJavaScriptEngine.MsieJsEngine.CallFunction(String functionName, Object[] args)
     at JavaScriptEngineSwitcher.Msie.MsieJsEngine.InnerCallFunction(String functionName, Object[] args)
     at JavaScriptEngineSwitcher.Msie.MsieJsEngine.InnerCallFunction[T](String functionName, Object[] args)
     at JavaScriptEngineSwitcher.Core.JsEngineBase.CallFunction[T](String functionName, Object[] args)
     at React.JavaScriptEngineUtils.CallFunctionReturningJson[T](IJsEngine engine, String function, Object[] args)
     at React.ReactEnvironment.ExecuteWithBabel[T](String function, Object[] args)
     at React.Babel.TransformWithSourceMap(String input, String filename)
     at React.Babel.TransformWithHeader(String filename, String contents, String hash)
     at React.Babel.TransformAndSaveFile(String filename)
     at React.MSBuild.TransformBabel.ExecuteInternal()
     at React.MSBuild.TransformBabel.Execute()
     at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
     at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
     at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
     at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask)
     at Microsoft.Build.BackEnd.TaskBuilder.<InitializeAndExecuteTask>d__24.MoveNext()
     at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
     at Microsoft.Build.BackEnd.TaskBuilder.InitializeAndExecuteTask(TaskLoggingContext taskLoggingContext, ItemBucket bucket, IDictionary`2 taskIdentityParameters, TaskHost taskHost, TaskExecutionMode howToExecuteTask)
     at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteBucket>d__19.MoveNext()
     at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
     at Microsoft.Build.BackEnd.TaskBuilder.ExecuteBucket(TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask, Dictionary`2 lookupHash)
     at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteTask>d__18.MoveNext()
     at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
     at Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask(TaskExecutionMode mode, Lookup lookup)
     at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteTask>d__13.MoveNext()
     at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
     at Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask(TargetLoggingContext loggingContext, BuildRequestEntry requestEntry, ITargetBuilderCallback targetBuilderCallback, ProjectTargetInstanceChild taskInstance, TaskExecutionMode mode, Lookup inferLookup, Lookup executeLookup, CancellationToken cancellationToken)
     at Microsoft.Build.BackEnd.TargetEntry.<ProcessBucket>d__48.MoveNext()
     at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
     at Microsoft.Build.BackEnd.TargetEntry.ProcessBucket(ITaskBuilder taskBuilder, TargetLoggingContext targetLoggingContext, TaskExecutionMode mode, Lookup lookupForInference, Lookup lookupForExecution)
     at Microsoft.Build.BackEnd.TargetEntry.<ExecuteTarget>d__42.MoveNext()
     at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)
     at Microsoft.Build.BackEnd.TargetEntry.ExecuteTarget(ITaskBuilder taskBuilder, BuildRequestEntry requestEntry, ProjectLoggingContext projectLoggingContext, CancellationToken cancellationToken)
     at Microsoft.Build.BackEnd.TargetBuilder.<ProcessTargetStack>d__22.MoveNext()
     at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)
     at Microsoft.Build.BackEnd.TargetBuilder.ProcessTargetStack(ITaskBuilder taskBuilder)
     at Microsoft.Build.BackEnd.TargetBuilder.<BuildTargets>d__11.MoveNext()
     at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
     at Microsoft.Build.BackEnd.TargetBuilder.BuildTargets(ProjectLoggingContext loggingContext, BuildRequestEntry entry, IRequestBuilderCallback callback, String[] targetNames, Lookup baseLookup, CancellationToken cancellationToken)
     at Microsoft.Build.BackEnd.RequestBuilder.<BuildProject>d__57.MoveNext()
     at System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1.Start[TStateMachine](TStateMachine& stateMachine)
     at Microsoft.Build.BackEnd.RequestBuilder.BuildProject()
     at Microsoft.Build.BackEnd.RequestBuilder.<BuildAndReport>d__49.MoveNext()
     at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)
     at Microsoft.Build.BackEnd.RequestBuilder.BuildAndReport()
     at Microsoft.Build.BackEnd.RequestBuilder.<RequestThreadProc>d__48.MoveNext()
     at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)
     at Microsoft.Build.BackEnd.RequestBuilder.RequestThreadProc(Boolean setThreadParameters)
     at Microsoft.Build.BackEnd.RequestBuilder.<StartBuilderThread>b__44_2()
     at System.Threading.Tasks.Task`1.InnerInvoke()
     at System.Threading.Tasks.Task.Execute()
     at System.Threading.Tasks.Task.ExecutionContextCallback(Object obj)
     at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
     at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
     at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot)
     at System.Threading.Tasks.Task.ExecuteEntry(Boolean bPreventDoubleExecution)
     at System.Threading.Tasks.ThreadPoolTaskScheduler.LongRunningThreadWork(Object obj)
     at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
     at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
     at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
     at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
     at System.Threading.ThreadHelper.ThreadStart(Object obj)

[ghotiphud]

I've seen it mentioned multiple times that you can switch the JsEngine to V8, which seems to be a bit more stable. I've tried editing the app.config to remove the MsieJsEngine, but I'm still seeing the same error, which leads me to believe that maybe the JsEngine is hard coded for React.MSBuild? If not, could you help me figure out how to switch so I can move forward with this?

[anatolitrifonov]

Folks sorry if this is offtopic. You keep referring to javascript engine in your replies
Example

I've seen this error myself several times, but only when using the MSIE JS Engine. I reported it to the developer of the MSIE JS engine library here: Taritsyn/MsieJavaScriptEngine#7

I can not seem to find a document explaining how to pick the js engine used by React.Net
Any reference please?
I switched to .Net Core latest release and now getting the same
"Exception thrown: 'System.AccessViolationException' in MsieJavaScriptEngine.dll"

Is there a work around?

[Daniel15]

You can disable the MSIE engine by calling .SetAllowMsieEngine(false) in your ReactConfig for ASP.NET 4, or when adding the middleware for ASP.NET Core.

[defcon84]

Is there any information / progress on this? We are rendering everything in clientOnly modus because of this exception.

[anatolitrifonov]

I was able to able to resolve or work around by doing this .SetAllowMsieEngine(false) plus copying ClearScriptV8-32.dll, ClearScriptV8-64.dll, v8-ia32.dll, v8-x64.dll into project root folder.
Added this to project.json to be able to run on local machine.
"buildOptions": {
"emitEntryPoint": true,
"preserveCompilationContext": true,
"copyToOutput": {
"include": [ "ClearScriptV8_.dll", "v8-_.dll" ]
}

},
Also added copy of these file to $packOutput during deployment.
Works.
example of copy script from "file system-publish.ps1"
$items = $PWD.ToString() + "\ClearScriptV8-32.dll"
Copy-Item -Path $items -Destination $packOutput
$items = $PWD.ToString() + "\ClearScriptV8-64.dll"
Copy-Item -Path $items -Destination $packOutput
$items = $PWD.ToString() + "\v8-ia32.dll"
Copy-Item -Path $items -Destination $packOutput
$items = $PWD.ToString() + "\v8-x64.dll"
Copy-Item -Path $items -Destination $packOutput
Work on Azure too

[defcon84]

I tried that and got the following:

DirectoryNotFoundException: Failed to load the ClearScriptV8 assembly, because the directory 'C:****\src\EBv2.UI\bin\Release\net461\win7-x64\ClearScript.V8' does not exist.

[aaron-hardin]

The answer provided by @anatolitrifonov worked for me, it seems that the JavaScriptEngineSwitcher.V8.props is not correctly processed so the V8 dlls are not registered as dependencies.
I am running MVC 6, with .NET 4.5.2, in case that helps.

[defcon84]

@Daniel15 could you test this: turn of anti-virus and run again
( microsoft/Chakra-Samples#4 )

[Daniel15]

For anyone encountering this error, could you please try upgrading the MsieJavaScriptEngine package to 1.7.4 1.7.2 and see if it still occurs? Its developer has mentioned that there's a potential fix in this version of MsieJavaScriptEngine.

Thanks!

[defcon84]

I think you mean 1.7.2? This version did not fix the issue for me.

[bouassaba]

1.7.2 did not fix the issue for me neither.
@Daniel15 I tried to find MsieJavaScriptEngine version 1.7.4 in github repository by looking at the tags, and also in nuget.org but without success, any suggestions ?

[Daniel15]

Oops, sorry, I meant MsieJavaScriptEngine 1.7.2.

I'll probably just drop MSIE support soon, or change it to only use the new open-source release of Chakra.

I had another look at ClearScript, and the only reliable way I could find to copy over the ClearScript DLLs in an ASP.NET Core project without checking them into the project repo was to have an ugly xcopy postcompile script in project.json:

  "scripts": {
    "postcompile": [
      "xcopy /Y C:\\Users\\Daniel\\.nuget\\packages\\JavaScriptEngineSwitcher.V8\\1.5.2\\content\\ClearScript.V8 %compile:RuntimeOutputDir%\\ClearScript.V8\\*"
    ]
  }

This is super-ugly since it has the local NuGet package path hard-coded, but it seems to work fine. Alternatively, just copy them to your project's root directory then use copyToOutput like @anatolitrifonov mentioned above.

Doing something like that and also adding .SetAllowMsieEngine(false) to the config should work to avoid this issue.

[Daniel15]

Sorry I took so long to get around to this issue! I've been pretty busy 😞

I just wrote a blog post summarising this issue: http://reactjs.net/2016/08/protected-memory-exceptions-and-dotnet-core.html. Basically, switching to V8 appears to fix the issue in every case I've seen. It's bit tricky for ASP.NET Core projects as you need to update them to properly copy over the ClearScript.V8 directory, but I've included instructions in the blog post. Luckily, that issue will go away with JavaScriptEngineSwitcher 2.0, which will handle this in a different way.

I'm going to close out this issue due to the fact that I haven't seen it occur at all once switched to V8 instead of MSIE. Please feel free to reopen it if you still see this exception even after switching to V8. For instructions on how to use V8, refer to the site at http://reactjs.net/2016/08/protected-memory-exceptions-and-dotnet-core.html.

[mwethington]

We are still having issues with V8.

[Daniel15]

@mwethington - Could you please provide a stack trace? So far I've only seen this error with the MSIE JS engine in the stack trace.

[mwethington]

Carl – please provide a stack that we can share with Daniel

From: Daniel Lo Nigro [email protected]
Reply-To: "reactjs/React.NET" [email protected]
Date: Thursday, September 15, 2016 at 1:23 AM
To: "reactjs/React.NET" [email protected]
Cc: Bill Bell [email protected], Mention [email protected]
Subject: Re: [reactjs/React.NET] JSX on-the-fly compilation results in AccessViolationException on ASP.NET 5 MVC 6 (#281)

@mwethingtonhttps://github.com/mwethington - Could you please provide a stack trace? So far I've only seen this error with the MSIE JS engine in the stack trace.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/281#issuecomment-247255637, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA4V-mfaQSt4PCJPWSNTyQb-LLWoXTFHks5qqPJ3gaJpZM4IyDnO.

[LClauss]

had myself depending on the computer i used for my project ( using React.MSBuild 3.0)

the Unhandled Exception: System.AccessViolationException ...

i had to disable and than re-enable the windowbase reference on my project

[peisheng]

any solution for it? i also meet the problem

[olivierr91]

Same problem here

[Taritsyn]

@orobert91 It seems to me, that this issue is no longer relevant, because all the major problems associated with the JavaScriptEngineSwitcher.Msie and JavaScriptEngineSwitcher.ChakraCore were solved in version 2.2.0.

[Daniel15]

@orobert91 - Did you try upgrading to the very latest JavaScriptEngineSwitcher?

[olivierr91]

Yes, I am not sure this is the exact thing that solved the issue (because I tried a lot of stuff) but I did not run into the error message since then...

[Jamo10]

#281 I am not pretty sure if this is the best place to mention it but this issue is still happening, at least for MVC version. I am using JavaScriptEngineSwitcher.Msie version = 2.4.9.0 & JavaScriptEngineSwitcher.ChakraCore version = 2.4.8.0, so I think this is not about upgrading that library.

The stack trace is the same:

System.AccessViolationException was unhandled
Message: An unhandled exception of type 'System.AccessViolationException' occurred in MsieJavaScriptEngine.dll
Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Any idea?

[Taritsyn]

@Jamo10 To begin, I recommend you upgrade to latest stable version of the JavaScript Engine Switcher (version 2.4.10).

Then you must explicitly register a JS engines and set default engine (in your case MsieJsEngine). How to register engines, read the “Registration of JS engines” section of documentation. JS engines must be registered before to the React.NET's services.

If after all these actions an error occurs, send me an error message with the full stack trace.