I have a MATLAB mex file which does not work, giving me the "The specified module
could not be found." error. Now, I understand that probably the issue is that it tries to link\call\whatever dll's which are missing. I'd like to figure out which ones so that I can provide them.
Here it is explained how to use the Dependency Walker to generate a text file which supposedly has this information. I generated the file but it's a huge one and I am at a loss as to where exactly the information about the missing files is.
I am thus looking for advice on how to locate the missing files reports in the Dependency Walker output.
One way might be to run Process Monitor, filter (Ctrl+L) processes to matlab.exe, and inspect lines with 'file name not found' immediately after calling your mex.
I can suggest another way - but it is more complicated and involves attaching a debugger to matlab. Don't go there unless Process Monitor fails to address this.
Related
Is there any way to download gradle-kotlin-dsl-6.6.1.jar source file by idea or manually with a link?
I wanted to read the source code of the functions in this dependency, I couldn't find the source code also.
I reasoned that, since the plugin is working for me, the code must've been downloaded. What I've found is that (in Android Studio under Linux), if I ctrl-click on a keyword in (anything, I think, but in this case) a build.kts file it takes me to the definition.
Doing this, I can then hover my cursor on the tab name and it shows me where the file is. Mine is way down under /.gradle, but the point is it does tell me where.
So, while I haven't found the jar file itself, I'm thinking that each of the files found like this are part of it. Does that help enough, or at least a bit?
When you try to run a program on Windows, and the loader can't find all of the required DLLs, the default behavior is to pop up a dialog box that describes the problem, including both the name of the program and the name of (one of the) missing DLLs. The process then hangs until someone clicks OK, and then exits with an error code. Here's an example of this dialog box:
Now suppose you're scripting some automated process that might fail for this reason, e.g. running CI tests after installation, where part of the point is to make sure the installer installs all the DLLs. You don't want your build workers to hang waiting for someone to click on a dialog box that's being displayed on a monitor that the computer physically does not have because it's in a server rack somewhere. You want the test cycle to stop immediately and the details to get written to the log.
Your build driver can disable this dialog box for itself and all its child processes (assuming nobody uses CREATE_DEFAULT_ERROR_MODE) by calling SetErrorMode:
SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX | SEM_NOOPENFILEERRORBOX);
hProc = CreateProcess(...);
However, this only solves half of the problem. The offending process will terminate with an exit status of 0xC0000135 (STATUS_DLL_NOT_FOUND), but the name of the problem executable and the name of the missing DLL are not reported anywhere that I can find it.
So here's the actual question: From code running in the build driver, how do I get the name of the problem executable and the name of the missing DLL, so that I can write them to my CI build logs? Anything goes, except that the code of the problem executable itself and its DLLs cannot be modified (because this is supposed to be a general solution) and an approach that does not require elevated privileges is strongly preferred.
(This is a follow-up question for Suppress "The program can't start because X.dll is missing" error popup . I've been vaguely meaning to write it for years now.)
Even though it's a little overkill, you could write a program/script that parses the PE format of each executable, walks its import table to enumerate imported modules, and checks to see if each module exists on the system (i.e. is it in \Windows\System32, the current directory, etc).
Then, if the executable in question is missing an import, log the executable and the missing import somewhere (and don't run the executable, of course).
If you want to do this in Python, the pefile module is excellent (https://pypi.org/project/pefile/).
(Update: This won't work for DLLs that are imported via LoadLibrary)
my friend has made a really helpful class library which I use all the time. I usually use Reflector to see what his code does.
What I really wanted to do was to step through his code while I'm debugging. So he gave me his .pdb file.
Foo.dll (release configuration, compile)
Foo.pdb
Now, I'm not sure how I can get it to auto break into his code when it throws an exception (his code, at various points, thorws exceptions .. like A first chance exception of type 'System.Web.HttpException' occurred in Foo.dll ...
Can I do this? Do i need to setup something with the Symbol Server settings in Visual Studio ? Do i need to get the dll compiled into Debug Configuration and be passed the .dll and .pdb files? Or (and i'm really afraid of this one) .. do i need to have both the .dll, .pdb AND his source code ...
I also had a look at this previous SO question, but it sorta didn't help (but proof I've tried to search before asking a question).
Can someone help me please?
Yes you can, if your friend indexes those PDB's, so that the debugger knows where to find the appropriate source in a source-control system, and if your friend uploads those pdb's to a symbol-server, you can perfectly step through the code while debugging.
I have done this for some projects at work, and this works like a charm.
More info about setting up a symbol server:
Source server helps you kill bugs
Setting up a symbol server
Using symstore
The answer is in in the linked question, though perhaps it's not blindingly obvious, so I'll say it: yes, you need to have the source code in order to step through the source code. The PDB file only tells the debugger what line of what source file corresponds to a particular machine instruction.
You don't need to set up a "symbol server" or anything like that. Just get him to send you the source. When you load the PDB file Visual Studio will prompt for the location of the source files if they're not at the same path.
I guess you posted link to another question just to prove that you have searched because that question does have an answer to your question.
I'm trying to reverse-engineer a program that does some basic parsing: text in, text out. I've got an executable "reference implementation" and the source code to what must be a different version, since the compiled source output != executable output.
The process creates and deletes temporary files very quickly in a multi-step parsing process. If I could take a look at the individual temporary files, I could get some great diagnostic data to narrow down where my source differs from the binary.
Is there any way to do any of the following?
Freeze a directory so that file creation will work but file deletion will fail silently?
Run a program in "slow motion" so that I can look at the files that it creates?
Log everything that a program does, including any data written out to files?
Running a tool like NTFS Undelete should give you the chance to recover the temporary files it's creating then deleting. Combine this with ProcMon from Sysinternals to get the right filenames.
You didn't mention what OS you're doing this on, but assuming you're using Windows...
You might be able to make use of SysInternals tools like Process Explorer and Process Monitor to get a better idea of the files being accessed. As far as I know, there's no "write-only" option on folders. For "slowing down" the files, you'd just need to use a slower computer. For logging, the SysInternals tools will help out quite a bit. Once you have a file name(s) that are being created, you could try preventing their deletion by opening the files in a stream from another process. That would prevent the system from being able to delete them.
There are two ways to attack this:
Run various small test cases through both systems and notice the differences. Since the test cases are small, you should be able to figure out why your code works differently than the executable.
Disassemble the executable and remove all the "delete temp file" instructions. Depending on how this works, this could be a very complex task (say when there is no central place where it happens).
I've run into a problem that's driving me crazy, hopefully someone will be able to shed some light on it. As part of my build process I have a separate .exe that updates the VersionInfo for the file. I literally use this on more than 20+ programs, but for some reason on one of them it is removing all the existing resource information from the exe. I actually trimmed it down and I can get the exact behavior by just calling:
if ((ResourceHandle = BeginUpdateResource(Target, FALSE)) != NULL)
{
EndUpdateResource(ResourceHandle, FALSE);
}
I use the above as a simple example, but in my case I'm checking the return codes and everything is operating properly. If I run the same code against my 20 other apps, they are unaffected by it - but run it on this one and it removes the resource data.
I looked through the .rc file, removed chunks of it, rebuilt it every way I could think of, and the result is the same. I can also load it up in DevStudio, and it doesn't report that anything is corrupt, etc. The build process is exactly the same between all the apps (they're built via makefiles, so no magic happening in there either).
Has anyone else experienced this sort of behavior? It looks like other people have encountered it here.
But so far I haven't found a solution...
As part of my build process I programmatically edit the source code for the version number (in the resource source file), instead of editing the *.exe ... so I couldn't get that problem.