Thanks for answer. DOSBox is a great emulator and very useful not only to play, but also to debug. I'll give it a try and try to load the BIOS in memory and then do a JMP FFFF:0 Let's see if I can somehow get further.
I'm having an issue with memdump/memdumpbin - for some reason it's not producing a memory dump. I've tried with and without running the program under DEBUG (MS-Debug). DosBox gives me the correct log message of "DEBUG: Memory dump success.", however I cannot find memoydump.txt/bin under my current directory, where DosBox is installed, or where the program I'm debugging is installed. I've also done multiple full-system searches for these files and they do not exist.
EDIT: I just downloaded DOSBox-X and this feature appears to work. File is saved in the mounted directory as expected.
Alek wrote on 2023-05-01, 01:35:I'm having an issue with memdump/memdumpbin - for some reason it's not producing a memory dump. I've tried with and without running the program under DEBUG (MS-Debug). DosBox gives me the correct log message of "DEBUG: Memory dump success.", however I cannot find memoydump.txt/bin under my current directory, where DosBox is installed, or where the program I'm debugging is installed. I've also done multiple full-system searches for these files and they do not exist.
It looks like it should be "MEMDUMP.TXT" in your current working directory, presumably in ugly uppercase if you have a case-sensitive filesystem. Would your searches have picked that up?
doshea wrote on 2023-05-02, 09:25:Alek wrote on 2023-05-01, 01:35:I'm having an issue with memdump/memdumpbin - for some reason it's not producing a memory dump. I've tried with and without running the program under DEBUG (MS-Debug). DosBox gives me the correct log message of "DEBUG: Memory dump success.", however I cannot find memoydump.txt/bin under my current directory, where DosBox is installed, or where the program I'm debugging is installed. I've also done multiple full-system searches for these files and they do not exist.
It looks like it should be "MEMDUMP.TXT" in your current working directory, presumably in ugly uppercase if you have a case-sensitive filesystem. Would your searches have picked that up?
Yes as I explained above I did a full system search and searched in all the logical places, however DosBox-X has this feature working just fine - it puts it where the fs is mounted.
In the debugger, the MEMDUMP command creates a text file named MEMDUMP.TXT, the MEMDUMPBIN command creates a binary file named MEMDUMP.BIN. The files are created in the current directory, sometimes referred to as the working directory, which is not necessarily the same as a mounted directory although it might be. On Windows, if the DOSBox executable is run directly then the current directory is where the executable is located, but if run through a shortcut then the current directory is where the shortcut specifies (i.e., the "Start in" textbox of the shortcut). If the dump files are not being created then perhaps the current directory is invalid in the shortcut or access rights are insufficient to create files in the current directory.
ripsaw8080 wrote on 2023-05-03, 07:48:In the debugger, the MEMDUMP command creates a text file named MEMDUMP.TXT, the MEMDUMPBIN command creates a binary file named MEMDUMP.BIN. The files are created in the current directory, sometimes referred to as the working directory, which is not necessarily the same as a mounted directory although it might be. On Windows, if the DOSBox executable is run directly then the current directory is where the executable is located, but if run through a shortcut then the current directory is where the shortcut specifies (i.e., the "Start in" textbox of the shortcut). If the dump files are not being created then perhaps the current directory is invalid in the shortcut or access rights are insufficient to create files in the current directory.
Would DosBox give me the "DEBUG: Memory dump success." message if creating the file has failed due to access rights?
I wouldn't think so, but then I'd also think the file is being created. What is the current directory in your case?
i also always got trouble easily finding the output files - so i just added a fixed path to all my needed output files memdump, cpulog etc. - maybe also a solution for you or a way to check if the file isn't generated at all (for whatever reason)
ripsaw8080 wrote on 2023-05-04, 05:00:I wouldn't think so, but then I'd also think the file is being created. What is the current directory in your case?
I just tested again by running as an admin. Again for some reason this works with DOSBox-X and not regular DOSBox. My mount is in C:\dosprogs, DOSBox-X runs out of my user Downloads folder, DOSBox runs out of C:\Program Files, that's why I thought maybe its a permissions issue. Just to reiterate, I've done full system scans for the files in case I missed obviously places where the memdumpbin/memdump would put the files. The file creation is likely failing, and although I haven't looked at the source - I'm certain there are probably some additional checks to verify the file was created, written, and closed correctly. Perhaps also add to the DEBUG message, "Wrote file to: <location>". For now I have to use DOSBox-X because the binary I'm working with is packed, so I need to dump out the unpacked segments. Sorry to be a nuisance; I'd check the source and do further testing if this wasn't on subversion 🙁
"Program Files" is likely the problem, as you'd tend to run into UAC. You could try making a shortcut that puts the current directory somewhere not restrictive; or just put the vanilla debugger executable where you're putting the fork executable.
The SaveMemory() code in DOSBox-X appears no different than that in official source, so the environment given to the respective programs decides the results.
I ran as admin and it still didn't work, I'll try moving to a user directory. In this case the file create would still fail, so I think there should be error checking at least instead of saying the dump was saved.
Alek wrote on 2023-05-06, 14:18:I ran as admin and it still didn't work, I'll try moving to a user directory. In this case the file create would still fail, so I think there should be error checking at least instead of saying the dump was saved.
Writes from unprivileged programs to Program Files don't fail, they get redirected to user\AppData\Local\VirtualStore\Program Files.
At least in 0.74-3, in the MEMDUMP* commands there is error checking for the call to fopen(), but not for the calls to fprintf()/fwrite()/fclose(). Sorry, I'm not going to offer a patch for this as I don't have a build tree set up and haven't built DOSBox in a very long time!
jmarsh wrote on 2023-05-06, 20:36:Alek wrote on 2023-05-06, 14:18:I ran as admin and it still didn't work, I'll try moving to a user directory. In this case the file create would still fail, so I think there should be error checking at least instead of saying the dump was saved.
Writes from unprivileged programs to Program Files don't fail, they get redirected to user\AppData\Local\VirtualStore\Program Files.
I scanned my entire computer for the files and they never show up regardless, it only works with DosBox-X. I haven't got around to moving my DosBox install to a user directory, but regardless I'm very certain that the files are not being created.
Edit: Also yes, they will fail with error code 5 if its a permissions issue. Not sure where you are getting this information about VirtualStore.
