Manage code problem

May 29, 2014 at 7:07 PM

I have recently upgraded my project from Javascript.Net to ClearScript with V8.

Currently, when I'm running the webdev server I fairly frequently get this error:

The program '[6484] WebDev.WebServer40.EXE: Managed (v4.0.30319)' has exited with code 1073741855 (0x4000001f).

This is the same error I got when dealing with Javascript.Net, and it is the biggest reason why I made the switch.

I looked into the problem and it seems to have to do with 32bit dlls in a 64bit program. Or calling c++ code from c# (something about marshalling issues?) The compiled clearscript.dll is 32bit. How can I force it to use the 64 bit dlls that were also built? How would I make the clearscript.dll 64bit (I tried and was not successful).

Is this even the problem? Is there a special procedure to create a 64bit version? How can I make it more stable?

~Scott M.
May 30, 2014 at 4:37 PM
Edited May 30, 2014 at 4:44 PM
Greetings Scott!

Hmm, we don't have much to go on here, so all we can offer is some clarification:
  • Unless you've built it from modified source code, ClearScript.dll is architecture-neutral and can be loaded into both 32- and 64-bit processes.
  • ClearScriptV8-32.dll and ClearScriptV8-64.dll (and the respective native V8 libraries) are not architecture-neutral. When you first instantiate a V8-based ClearScript class, the main library detects the architecture and loads the appropriate ClearScriptV8 library.
  • In general, 32-bit libraries cannot be loaded into 64-bit processes, and vice versa.
Also, you mentioned that you looked into the problem. Can you let us know what you found? Specifically, what led you to believe that the problem was with ClearScript?

May 30, 2014 at 5:14 PM

That's interesting about ClearScript.dll. I'm not sure I follow that it can be either, When I run a dll diagnostic on it it says it's a 32 bit one. However, it's not that bit of a deal, I just have to check the 'allow 32 bit applications' in my IIS app Pool. This appears to be more of an optimization task that I'll have to tackle at a later date.

So more detail about the 1073741855 exit code problem. I'm running an MVC3 web-application. A crash would occur within two minutes if I was running it in the debug environment and closed out of a session by closing the browser. The crash would happen when I restarted the browser for a new session. Quick background: I'm developing survey software that uses ClearScript as a method to control branching logic etc. Each time I hit the 'next' button it reinstantiates the formula engine (with clearscript).

After I included the 'dispose' method at the end of my code for each time I hit 'next' (so right before it serves up the html) the problems disappeared. I had used dispose with Javascript.Net and while it reduced the number of crashses it certainly didn't eliminate it. Your dispose method however seems to be vastly superior. Granted, there has only been a day of testing, but I have yet to see another 1073741855 exit code problem!

I suspect that the rapid reinstantiations without using dispose caused some memory access problems which in turn caused the crash.

Thank you for your quick feedback!
May 30, 2014 at 8:15 PM
Edited May 30, 2014 at 10:56 PM
Hi again!

It's great to hear that you've found a solution!

As for ClearScript.dll, .NET libraries can be built to target the so-called AnyCPU platform (please see here), which just means that the same library file can be loaded in both 32- and 64-bit processes. Is it possible that your diagnostic tool doesn't recognize such libraries?

In any case, ClearScript.dll isn't an executable, so it can't dictate whether a process is 32- or 64-bit. There must be something in your project or IIS configuration that forces 32-bit process creation.

Good luck!