We Keep Coding

R.NET works with x86 but not x64

I'm trying to build and run the Hello World sample at the tutorial page at R.NET. When I force the program to run in x86 mode, it seems to do OK. However, when I run in x64, it stops very early on with the message, "[program] exited with code-1073740791"
I've installed the latest version of R at The R Project and have ran the troubleshooting steps. The output I've gotten from the troubleshooting program is:
Is this process 64 bits? True
Info: caller provided rPath=null, rHome=null Info: R.NET looked for preset R_HOME env. var. Found null
Info: Found Windows registry key RDotNet.NativeLibrary.WindowsRegistryKey
Info: Found Windows registry key RDotNet.NativeLibrary.WindowsRegistryKey
Info: Found sub-key InstallPath under RDotNet.NativeLibrary.WindowsRegistryKey
Info: InstallPath value of key RDotNet.NativeLibrary.WindowsRegistryKey: C:\Program Files\R\R-4.0.3
Info: R.NET looked for platform-specific way (e.g. win registry). Found C:\Program Files\R\R-4.0.3
Info: R.NET trying to find rPath based on rHome; Deduced C:\Program Files\R\R-4.0.3\bin\x64
C:...\bin\x64\Debug\net5.0\ConsoleNet5R.exe
(process 33500) exited with code -1073740791.
I have verified that there IS a file R.dll where it deduced it should be, "C:\Program Files\R\R-4.0.3\bin\x64". When I step through using my decompiler, it appears that it gets choked up at what is showing up for me as line 400 in REngine.cs, under the function "Initialize" at this.GetFunction<setup_Rmainloop>()(); It doesn't appear to throw an exception, it just stops. I'll be honest--I'm not sure what this line is supposed to be doing...
Any ideas what is going on? I can run in x86 mode if I have to, but I would like to use x64 if possible.

This issue has been reported for a while..
I experienced the same with R-4.0.3 to R-4.0.5.
There is not such issue for R-4.0.2 and former versions (4.0.1, 4.0.0, 3.6, 3.5)

I've done an analysis of this and tracked findings in one of the RDotNet GitHub issues where this was raised (https://github.com/rdotnet/rdotnet/issues/139#issuecomment-898699993).
This appears to be related to the Control Flow Guard security feature enabled in Windows 10. This doesn't happen in the R programs themselves because they are compiled using a different compiler (gcc via mingw) than Microsoft's. However, the CFG feature is enabled for .NET binaries and there is something (sorry, I don't know the actual underlying root cause) in a change within R 4.0.3 in setjmp/longjmp calls that is causing the crash (see: https://github.com/wch/r-source/blob/trunk/src/gnuwin32/fixed/h/psignal.h#L44-L51).
Although you would actually be disabling a security feature, I have had some luck for now in modifying my program after it is compiled (you can set this as a post-build event). You will need to run something like: link /EDIT /GUARD:NO <yourapp>.exe, which disables CFG.
Thanks to https://github.com/dotnet/runtime/issues/11899#issuecomment-502195325 for providing the instructions needed for this workaround, and https://www.trendmicro.com/en_us/research/16/j/control-flow-guard-improvements-windows-10-anniversary-update.html for providing the amazing analysis of CFG that led to an understanding of what was going on.

Powershell WMI output doesnt match c# WMI output

First I would like to say thank you for helping me with this issue. I really appreciate your time and efforts.
The title sums it up pretty well however I will provide a few specifics. Basically if I pull my OS version using C# it returns the result 6.2 which is for Windows 8 even though my system is 8.1 which should return 6.3. After my research I found that this was a documented limitation inside of the System.Enviroment class, ... gotta love those "features".
I have found a way to deal with this by going into the reg and comparing my 6.2 result with the current version key under HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion however, this is a very risky operation as the reg info could change without notice.
It all got screwy on me when I tried to poll WMI though Powershell. I can't remember why I did a WMI search though Powershell, I guess its not just cats that get curious :)
C# Code:
string version = Environment.OSVersion.ToString();
MessageBox.Show(version);
//Output "Microsoft Windows NT 6.2.9200.0"
Powershell Code:
[System.Environment]::OSVersion | Select-Object -Property VersionString
//OUtput "Microsoft Windows NT 6.3.9600.0"
I have tried both x86 and x64 builds of my C# program as well as running the Powershell both x86 and x64. The discrepancies did not change.
This raises several questions for me but the basic one is where does Powershell get the correct info from? Does Powershell use the reg like I had planned to fix its output? Since my build targets .Net 3.5 does Powershell pull .Net 4.5 (changed my build and this changed nothing).
From my understanding [System.Environment]::OSVersion pulls info the same as System.Environment.OSVersion.
How the heck does Powershell work and C# fails??
:)
Thanks again!

As far as I can tell only the Environment.Version call in a C# program is incorrect (6.2). In PowerShell it is correct (6.3). In WMI called via PowerShell or C# it is correct. In fact, C# compiled from source in PowerShell using Add-Type returns 6.3.
Looking into the article here (thanks Booga Roo) it indicates that unless your application specifically says it targets Windows 8.1 via a manifest file, you get the old version (6.2).
You can make a C# application return the correct version by adding an application manifest file and declaring 8.1 support by uncommenting the line
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
It seems safe to assume that the writers of PowerShell at Microsoft included an application manifest with powershell.exe that declares Windows 8.1 support.

Import scikit in C# application

I am trying to import scikit-learn in a C# (console) application. I am using Python Tools for Visual Studio and IronPython 2.7.3.
I managed to run an external python script and I also managed to import numpy by declaring the python path: "C:\Python27\Lib\site-packages\"
However, when it comes to scikit-learn I get an error message:
Oops! We couldn't execute the script because of an exception: No module named _c
heck_build
___________________________________________________________________________
Contents of C:\Python27\Lib\site-packages\sklearn\__check_build:
setup.py setup.pyc setup.pyo
_check_build.pyd __init__.py __init__.pyc
__init__.pyo
___________________________________________________________________________
It seems that scikit-learn has not been built correctly.
If you have installed scikit-learn from source, please do not forget
to build the package before using it: run `python setup.py install` or
`make` in the source directory.
If you have used an installer, please check that it is suited for your
Python version, your operating system and your platform.
The file "_check_build.pyd" exists in "C:\Python27\Lib\site-packages\sklearn__check_build\".
My code is based on this article: http://devleader.ca/2013/09/23/visual-studio-c-python-sweet/
The file I am using has only the following code:
from sklearn.svm import SVC
print('Hello Python in C#')
Is it possible to add and use scikit in C#? If yes, could you please provide a workaround?

Looks like scikit-learn requires a C extension, which means it won't run under IronPython.

How to statically-link MKL v9.x into a managed C++ DLL to calculate FFT?

I'm coding an application using C# with Visual Studio 2008. I've been reading the documentation that came with the Intel Math Library...and some forums...but couldn't get an answer.
Here is where I'm at:
Scenario:
Attempting to statically-link MKL v9.x into a managed C++ DLL to calculate FFT, using Visual Studio 2008.
Linker command:
/OUT:"C:\Projects\Acquisition Toolkit\Mainline\Builds\Debug\AcquisitionToolkit.FFT.dll" /INCREMENTAL /NOLOGO /LIBPATH:"C:\Projects\Acquisition Toolkit\Mainline\Lib\Win32" /DLL /MANIFEST /MANIFESTFILE:"Debug\Win32\AcquisitionToolkit.FFT.dll.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /ASSEMBLYDEBUG /PDB:"c:\Projects\Acquisition Toolkit\Mainline\Builds\Debug\AcquisitionToolkit.FFT.pdb" /DYNAMICBASE /FIXED:No /NXCOMPAT /MACHINE:X86 /KEYFILE:"AcquisitionToolkit.snk" /ERRORREPORT:PROMPT mkl_c.lib mkl_ia32.lib libguide40.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib
Getting an unresolved external when linking:
1>FFT.obj : warning LNK4248: unresolved typeref token (0100000E) for 'DFTI_DFT_Desc_struct'; image may not run
At run-time, it crashes on the call to DftiCreateDescriptor, presumably because it didn't know the format of the descriptor struct:
// create the FFT descriptor
DFTI_DESCRIPTOR_HANDLE desc;
long val = DftiCreateDescriptor(&desc, DFTI_DOUBLE, DFTI_REAL, 1, length);
// commit the FFT descriptor
DftiCommitDescriptor(desc);
We are including the mkl_dfti.h header file.
Are there additional header files we need or additional libraries we need to link with?
Where is that descriptor struct actually defined?
I attempted to dynamically link using the mkl_c_dll.lib, but got the same unresolved external linker warning.
Is there some other linker option I need?
Please if someone could give me some kind of guidance/help. I'd REALLY appreciate it.
Thanks!!

As far as I know you can only do dynamic linking with c++/clr, i.e. /clr is incompatible with /MT[d]. You need to link to a library compiled with /MD[d] so they use the same runtime. I don't know why it fails when you do dynamic linking but your theory of incorrect descriptor sounds right
Edit: By the way, I don't know if it is an option in your situation but you can use CUDA for doing FFT (cufft) much faster on the GPU.

P/Invoke C# to C++

I'm trying to learn how to run C# and C++ code together using Mono on RedHat. I'm fooling around in order to learn how to get the two to interoperate together in order to be a bit more educated when I work on a larger project.
I've got a problem that I'm making a P/Invoke call from the C# to my C++ code and an exception is being thrown. Using Mono, I can get the C++ code to call the C# code no problem.
My C++ method that I want the C# to call is as follows.
extern "C"{
void Foobar(){
printf("Hooray!");
}
}
My C# code that I have uses the following P/Invoke lines.
[DllImport ("__Internal", EntryPoint="Foobar")]
static extern void Foobar();
In my C# program, I call
Foobar();
further down in a function. The exception I catch is an EntryPointNotFound exception. I'm probably overlooking something silly.
I've used http://www.mono-project.com/Embedding_Mono as instructions regarding how to do this.
Any suggestions appreciated. Thanks,
mj

Are you using embedding (that is, you build your own executable that inits the mono runtime)? In that case the possibilitites are usually two:
You have a typo
The compiler/linker removed during optimization the function from your binary
To check for either, run:
nm your_program |grep Foobar
and see if a symbol with that name is present in the executable your_program.
If you see a mangled name it means extern "C" was not applied correctly in your code.
If you're not using embedding, you need to use the dynamic library name and not __Internal in DllImport (and check for typos and the above linker optimization issue as well).

Why "__Internal"? That's for P/Invoking symbols in the Mono runtime or the program embedding the Mono runtime. How is your C++ code being compiled and linked?

I saw this exact problem, objdump -T and objdump -t differed on the host binary.
It was missing the 'D' flag, which means add a -rdynamic to the gcc linker.