EACCES when not running under VS debugger
-
Hi I have a C DLL that processes data for a MFC C++ program. It happens to be my FTP folder where files are received from FTP. when I step thru the code under the VS debugger everything runs fine I make a breakpoint in the MFC code and when after getting the ProcAddress I go into the function. So how do I know what the problem is when I don't run under the VS debugger, well I have a SEH (handler that pops up with a messagebox and I attach the debugger and observe the rc from _sopen_s that fails) I decided to put a MessageBox in when it fails (in the DLL) and upon entry to the DLL as well, in the hope that I can then attach the debugger and get a better idea but the messagebox fails to appear I do re-link the MFC program as well I went as far a deleting the .lib TO ensure I was picking it up while linking the MFC program and I got a link error so I know its picking the .lib of the DLL I am running both the (VS Debugger and the MFC program in administrator mode)
-
Hi I have a C DLL that processes data for a MFC C++ program. It happens to be my FTP folder where files are received from FTP. when I step thru the code under the VS debugger everything runs fine I make a breakpoint in the MFC code and when after getting the ProcAddress I go into the function. So how do I know what the problem is when I don't run under the VS debugger, well I have a SEH (handler that pops up with a messagebox and I attach the debugger and observe the rc from _sopen_s that fails) I decided to put a MessageBox in when it fails (in the DLL) and upon entry to the DLL as well, in the hope that I can then attach the debugger and get a better idea but the messagebox fails to appear I do re-link the MFC program as well I went as far a deleting the .lib TO ensure I was picking it up while linking the MFC program and I got a link error so I know its picking the .lib of the DLL I am running both the (VS Debugger and the MFC program in administrator mode)
Well it could be any one of a million things, but without more information it is pointless trying to guess. Also deleting the .lib file does not guarantee that you are loading the correct .dll at execution time. You should start by rebuilding everything from clean to ensure that no component is out of sync. Secondly, and much more importantly, where does the
EACCESS* error occur, and what is the code trying to do at that point? *EACCESSis returned (most often) when trying to access some file/directory that is protected. And even when running in admin mode some things remain blocked. -
Well it could be any one of a million things, but without more information it is pointless trying to guess. Also deleting the .lib file does not guarantee that you are loading the correct .dll at execution time. You should start by rebuilding everything from clean to ensure that no component is out of sync. Secondly, and much more importantly, where does the
EACCESS* error occur, and what is the code trying to do at that point? *EACCESSis returned (most often) when trying to access some file/directory that is protected. And even when running in admin mode some things remain blocked. -
The EACCESS occurs on _sopen_s the only thing I can think of regarding that is that I have the path + filename and maybe the open function only takes a file name Regardless I’m gong you’re-build the DLL thanks
-
What exactly are you trying to open, and what sharing options are you using?
Quote:
EACCES The given path is a directory, or the file is read-only, but an open-for-writing operation was attempted.
It’s a mainframe z/os sysadata file which is a binary representation of Z/OS Assembler program listing I have all the big endian conversion routines for going from mainframe to pc it did work as I was able to display the listing in the richedit that called the DLL and processed this file thanks