none
_CRT_DEBUGGER_HOOK but working when running in cmd

    Question

  • Hello, I have simple program that can execute properly in cmd such as main.exe string1 string2. However, it throws _CRT_DEBUGGER_HOOK when I try run the debug command in VS2010. Now, is there any way to solve this problem. It run perfectly, but I need to run it via GUI using C# (Process.StartInfo.Arguments) which is currently fail. How to solve this.

    Update:

    Ok, after several hours figuring out, I found that my fopen function can't find the file in release folder. When I specify debug argument var.dat, it looks that fopen is trying to access my file in source directory (main.cpp directory), not my release directory. How to solve this problem?

    • Edited by takercena Saturday, February 11, 2012 10:21 PM Update
    Saturday, February 11, 2012 9:27 AM

Answers

  • This is known, when the VS debugger runs the executable, it sets the current directory to the project path (where the vcxproj file is). The problem you have is because you are assuming that the current directory is always set at startup to where the executable is located. To let you know, this is also a security flaw.

    The best approach to deal with this is to get the path to the executable and then use fopen in relation to that. You can use the GetModuleFileName function with the module parameter set to NULL to get the full path to the executable, (you could also try argv[0] for this, but what you get from here depends on what was typed in on the command line, so it could just be the executable name). What this gives you is the full path, including file name of the executable. If you then strip out everything past the final \, then you can use it to load files relative to the main executable without relying on the current directory being set.

    This may be annoying, but the current directory can be set easily, so it is best to not assume that using fopen("myfile.txt", "whatever"); will open a file in any specific directory. It also has greater implications, not only is this the same directory that files get loaded from, but if set right, DLLs can be loaded from here too. So this is why it is a security flaw.

    So any important files that you need to access should use an absolute path to the file.


    This is a signature

    Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Saturday, February 11, 2012 10:45 PM

All replies

  • We would need to see your code to really know what the issue is.
    Saturday, February 11, 2012 1:41 PM
  • We would need to see your code to really know what the issue is.
    Thanks for your reply. Please check my update.
    Saturday, February 11, 2012 10:22 PM
  • This is known, when the VS debugger runs the executable, it sets the current directory to the project path (where the vcxproj file is). The problem you have is because you are assuming that the current directory is always set at startup to where the executable is located. To let you know, this is also a security flaw.

    The best approach to deal with this is to get the path to the executable and then use fopen in relation to that. You can use the GetModuleFileName function with the module parameter set to NULL to get the full path to the executable, (you could also try argv[0] for this, but what you get from here depends on what was typed in on the command line, so it could just be the executable name). What this gives you is the full path, including file name of the executable. If you then strip out everything past the final \, then you can use it to load files relative to the main executable without relying on the current directory being set.

    This may be annoying, but the current directory can be set easily, so it is best to not assume that using fopen("myfile.txt", "whatever"); will open a file in any specific directory. It also has greater implications, not only is this the same directory that files get loaded from, but if set right, DLLs can be loaded from here too. So this is why it is a security flaw.

    So any important files that you need to access should use an absolute path to the file.


    This is a signature

    Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Saturday, February 11, 2012 10:45 PM
  • I just want to add, that you may have a look at
    Project Settings for a C++ Debug Configuration
    http://msdn.microsoft.com/en-us/library/kcw4dzyf.aspx
    to get more info about the settings Visual studio will use during debugging (including the current directory or "Working Directory").

    With kind regards

     

    Sunday, February 12, 2012 9:43 AM