I have been trying to load a mat file on my distributed computing environment. When I load running in a matlab terminal on any computer I can load it no problem. When I submit it as a job to my cluster it fails saying
Error using load
Bad version of endian-key
even though the version of matlab is identical. Just the environment is changed. I have stripped away everything to just simply
load ~/Desktop/model.mat
disp('Done');
exit;
and the problem persists. We are running this using Sun Grid Engine.
That particular error message can either mean the file is corrupted, or it can mean that the system failed to allocate memory while loading the data (and no, that isn't obvious from the message...)
Related
I want to run a Simulink model in real time. So I need the Real time sync block in "Simulink desktop real time" (sldrt) toolbox working. It seems to be correctly installed, also in path. But I always get the error:
Error in S-function 'real_time_test/Real-Time Synchronization': Unable to acquire handle to MATLAB function 'sldrtsync'
Component:Simulink | Category:Blockerror
This error occurs also with the Desktop real time example _sldrtex_vdp_ also see my minimal example that I cannot get working..
In the sldrt directory there are two files:
sldrtsync.mexw64
sldrtsync.tlc
This path is also included in Matlab Path.
API: Win7 64bit
Matlab R2016b
Windows SDK 7.1
Where to look for the solution?
I'm trying to build a minifilter driver to log all IRPs. Logging takes place in the driver itself (using FltCreateFile(), FltWriteFile()...).
Without specifying an altitude in the .inf file, the minifilter loads but does not attach to any volume. Manually attaching using fltmc attach also fails (Attach failed : incorrect parameter).
When specifying an altitude, fltmc load filter leads to BSOD.
Any idea what might be causing this?
The problem seems to be with the INF driver installation file. Making sure the Strings section of the INF file is correct (no typos) may help.
Creating a new Minifilter driver project solved the problem for me.
I'm new to using WinDbg and am running into a problem. I've set the server for symbols and downloaded them, but I keep getting stuck when I try to run !htrace (or any other command actually). The error message I get is
Cannot load 'ntsdexts'
I get this on any command that starts with an exclamation point (i.e. !drivers, !heap, !htrace, etc.) which is making tracking down a handle leak a problem.
I'm using the srv*...* link direct to Microsoft for symbols.
The last line before I get the breakpoint is:
Module Load: C:\WINDOWS\SYSWOW64\VFRCORE.DLL (no symbols loaded)
From the comments:
Somehow I managed to get two different version of windbg installed and the one in the path is the wrong one. Put the dll file into the right place, ran from that specific directory and now it works.
I have a SBCL program that works fine in the REPL (and I've successfully built it before), but after a few changes to the code, the build doesn't work anymore. It still successfully build, but running the binary gives me strange errors:
fatal error encountered in SBCL pid 940(tid 2953912320):
thread_state: os_sem_wait(0x1408000): 4, No such file or directory
It still works fine in the REPL (the binary is also in same folder)
What is the best way to debug this situation? So far, I've been just trying things and rebuilding -- is there a better way?
The ASDF central registry is temporarily extended with the --asdf-path and --asdf-tree
arguments at load time, and reverts back to the default central registry value after that.
To avoid conflicts with this behavior, changes to the central registry should be done at
startup time instead of application load time.
Buildapp. Implementation
So, if you use some asdf utility in runtime, it could cause such an error, I think.
Whenever I try to run this application (I didn't write it) that uses Crystl32.OCX, I get the error...
Run-time error '372':
Failed to load control 'CrystalReport' from Crystl32.OCX. Your version of
Crystl32.OCX may be outdated. Make sure you are using the version of the
control that was provided with your application.
For a long time, I was getting an error about Crystl32.OCX could not be found, but I ultimately managed to register it. However, it's not working properly now. Any ideas?
I solved this problem by reloading the Crystl32.ocx file and installing it in the path. C:\Windows\System\crystl32.ocx or C:\Windows\SysWow64\crystl32.ocx and you can download the update file this link ---> https://www.ocxme.com/files/crystl32_ocx