I have some trouble with my asp.net application which uses matlab functions inside.
I generated matlab function on matlab R2016a and then I generated Dll's via matlab compiler / dotnetbuilder.
At localhost, I build a MVC Web application with VS2013 which takes an integer input and on backend it generates random numbers counts input than matlab function gets the average of these random numbers.
However, it works fine on localhost but it fails on server with Matlab Compiler Runtime 9.0.1 installed. Exception is:
"Unable to load DLL 'mclmcrrt9_0_1.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)"
So I lookup with the dependency walker and I see this;
focused line is belong to the dll that generated via matlab Library compiler of R2016a
It says that matlabs generated dll is in cpu type of x86 even whole application is in x64.
Questions:
1) How can I fix this issue
2) Why this application runs with no exceptions on my own PC
any answers appreciated, if you need any other information just tell me.
I did the same and have the same problem, Problem didn't solve until I restart the server because of new Environment Variable which defined in windows system after installing Matlab RunTime.
so first restart server.
and be sure that you complied dll with matlab 64bits if use 64bits server.
Related
I have a Java 9 app that I'm trying to package for the Windows Store. The strange thing is that it works as expected when I run the exe-launcher directly, but I get the following strange error when I run the launcher via the APPX package:
Exception in thread "Swing-Shell" java.lang.InternalError: Could not
initialize COM: HRESULT=0x80010106
at java.desktop/sun.awt.shell.Win32ShellFolderManager2.initializeCom(Native Method)
at java.desktop/sun.awt.shell.Win32ShellFolderManager2$ComInvoker$1.run(Unknown Source at java.base/java.lang.Thread.run(Unknown Source)
HRESULT=0x80010106 means RPC_E_CHANGED_MODE which I guess means that COM is somehow already initialized in MTA mode. But why is this only an issue in the Windows Bridge sandbox? Does the Windows Bridge somehow pre-initialize COM somehow for some reason?
I'm not sure if this is a Java 9 issue, or a Desktop Bridge issue, or both. Does anybody have any ideas on how to identify the cause of the issue or workaround?
I have made a minimal Sample Project to reproduce the issue
The application works when executed directly, but not when executed via the APPX launcher. Why?
Analysis
The JDK parts, that rely on COM being initialized (D3DPipeline, Sound and windows shellfolder access) all follow the same pattern:
the run the code in a separate thread
for this thread CoInitialize is called
at the end of the user level code CoUnitialize is called
This is in line with the documentation the MSDN holds for COM and the analysis is correct, the error indicates, that the COM subsystem is already initialized to be MTA threaded.
So I modified the java launcher (jvm.dll) and inserted
debugging statements into some of the native methods in os_windows.cpp.
I focused on the threading methods. What I found was this:
create_main_thread, create_os_thread, pd_start_thread all
run with COM not yet initialized
the native thread initializer (thread_native_entry) is already
running with COM initialized
I looked more into in _beginthreadex and indeed I finally found a lead
on stackoverflow. That pointed me to the sourcecode of threadex.c,
which is part of the Visual Studio 2013 Express Installation.
There you find, that _beginthreadex does not directly start the
supplied thread function, but runs a library initializer
(_threadstartex) first. Part of this initializer reads:
_ptd->_initapartment = __crtIsPackagedApp();
if (_ptd->_initapartment)
{
_ptd->_initapartment = _initMTAoncurrentthread();
}
_callthreadstartex();
_crtIsPackagedApp detects via a kernel function if the application is
run as a "PackagedApp" (i.e. AppX package) and if so, then the
RoInitialize function is called, which from my understanding acts like the big
brother of CoInitialize.
Long story short: If your application is build with Visual Studio 2013
and run as a packaged application, you get a broken environment.
It was confirmed, that the working versions of the Oracle JDK were build with VS2010 SP1 and the broken version was build with VS2013SP4.
Workaround
With the above information google finally found a reference, that supports the analysis:
https://blogs.msdn.microsoft.com/vcblog/2016/07/07/using-visual-c-runtime-in-centennial-project/
Quote from that article:
Note that the existing VC++ 12.0 libraries created during the
Windows 8 timeframe have runtime checks to determine whether the
app is running under the app container or not. When running
desktop apps as a packaged app, these checks might limit the
functionality of the desktop app or cause it to behave like a UWA
(Universal Windows Application) (limited file system access or
create thread initializing MTA etc.). We have fixed this behavior
in the VC++ libraries contained in these framework packages and
thus removing the modern app limitations from your desktop
applications.
So I see to options to fix applications, that shall be distributed as AppX packages:
either force the users to have the updates VC++ 12.0 binaries installed (by introducing the dependency cited in the blog post) or
replace the msvcr120.dll that is bundled with Java 9 (and I assume also Java 10) with the fixed version from the update packages
I would go with the second version and I tested this. Starting with a clean up-to-date Windows 10 System, I installed JDK 9.0.4, I cloned the supplied testcase, modified it use the locally installed JRE (not the JDK!) and build the appx package. Running this, I reproduced the problem. I then replaced the msvcr120.dll's in the JRE folder of my systems installation with the one contained in the APPX container from:
https://www.microsoft.com/en-us/download/details.aspx?id=53176
Hint: *.appx are just ZIP files with additional signatures, so you can
just rename them and extract the contents.
I rebuild the testcase and it is working as it should (no COM
initialization errors anymore).
I have installed Desktop App Converter from the Windows store.
When I try to run the app (literally just launch it), I get the message:
[Window Title]
C:\Program Files\WindowsApps\Microsoft.DesktopAppConverter_2.0.2.0_x64__8wekyb3d8bbwe\DACTileLauncher.exe
[Content]
C:\Program Files\WindowsApps\Microsoft.DesktopAppConverter_2.0.2.0_x64__8wekyb3d8bbwe\DACTileLauncher.exe
The data area passed to a system call is too small.
I have tried running the Troubleshooter for Windows Apps, it tells me that "Windows Store cache and licenses may be corrupt" and tries to fix them, but running the troubleshooter a second time gives the same issue.
Each time I try to run the Desktop App Converter, I get 2 errors in Event Viewer:
%1: Cannot create the Desktop AppX container for package %2 because an error was encountered configuring the runtime.
%4: Cannot create the process for package %1 because an error was encountered while configuring runtime. %5
... both from AppModel-runtime
Any ideas how I can troubleshoot from here?
If you have problems with the Microsoft DAC you try this new converter, it is much easier to use, it has a GUI (no command line), built-in support for digital signing and allows you to customize the list of files that get inside your AppX.
Also, you can generate AppX packages for applications which do not (cannot) install silently.
It runs on Windows 7 too, not just Windows 10 (recommended).
have web setup project created by VS 2010, when i setup this project all works fine, but when i check "repair" option i get error during installation.
MSI log file
Running process 'c:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe' with parameters ' -norestart -sn ""' silently...
Process Call Result Code: '0' Process Exit Code: '1'.
The error indicates that IIS is in 32 bit mode, while this application is a 64 bit application and thus not compatible.
Trying 32 bit version of 'aspnet_regiis.exe'...
Reading registry value Path from key 'HKLM\Software\Microsoft\ASP.NET\4.0.30319.0'...
RESULT Path =
Running process 'c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe' with parameters ' -norestart -sn ""' silently...
Process Call Result Code: '0' Process Exit Code: '1'.
The error indicates that IIS is in 64 bit mode, while this application is a 32 bit application and thus not compatible.
I couldnt uderstand why both 32-bit and 64-bit versions of aspnet_regiis not compatible to application?
When i check "setup" not "repair" option, path param is set to my application and setup works fine, so maybe i have to change something in my setup project?
IIS6 is set to 64-bit mode by the way ;)
Thanks
If you support 32 and 64-bit systems you need separate setups for both.
http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx
so you'd run the appropriate aspnet exe for the system, that might solve some problems. You haven't said if your setup is x86 or x64, so it's hard to say what the exact issue might be. 32-bit processes cannot call 64-bit Dlls (and vice versa) so the 32-bit aspnet_regiis.exe can't call 64-bit assemblies in a 64-bit IIS, that's probably something to do with it.
That doesn't look like an MSI log file because it hasn't got all the info in there, like the MSI (s) (74:1C) [12:14:05:000]: type of intro, plust suff that would tell you if the call to the ProgramFiles folder is being redirected (look for WIN64DUALFOLDERS in the log).
I'm getting a problem with a project developed in C# with Emgu CV.
When I try tu run my program in one of my machines it works very well but, when i try to run at other machine (mine too) if doesnt work and show this error:
Can't find the entrance point at procedure clEnqueueCopyBufferRect at dll OpenCL.dll
This error only occurs in one machine.
Note: When i run the examples of EmguCV i get the same error.
Thanks
clEnqueueCopyBufferRect is OpenCL 1.1 API function. Does your machine has OpenCL 1.1 support?
Hoping that I do this corectly.
I am having the above issue. My development machine is win7 64. Im developing x86 application,(x86 set in compile options). I have downloaded sqlite-netFx40-setup-bundle-x86-2010-1.0.81.0 as my app will be on .net4. I have referenced the above dll, set it to copy local. Can confirm that its in the deployed dirrectory. Tests OK on development machine both as a debug and a fully instaled app. When I put the app on a separate win 7 64bit it wount run due to the Dll. It installs ok into ProgramFiles(x86) and runs untill the database is required. The dll is in the instaled dirrectory when instaled on the other PC. (fresh win instal).
I am using InstalShield and it is also telling me about an error ' -6248: Could not find dependent file system.data.sqlite.dll, or one of its dependencies of component' but it compiles OK.
Im stearing at the Dll in the program , in the references, the intelisence picksup the SQLite name and all the code is right. I have referenced by browse and then finding the dll.
What on earth could I be doing wrong ?
This has had so many views that I decided to answer this so as to help others.
The problem isnt a big deal once you know what it is, despite the error message that sends you almost in the wrong dirrection. The problem isnt the DLL, its one of its dependancies. Basicaly you have to install C++ distributable file on the client machine , even if you are using VB.net. I cant take credit for the find, it comes from here http://justanothersoftwareengineer.blogspot.com.au/2011/08/how-to-make-systemdatasqlitedll-work-on.html.