I have a process that changes its current directory, and I would like to know when and where it happens. How could I do that?
I tried setting a breakpoint in SetCurrentDirectoryA/SetCurrentDirectoryW with Visual Studio, but it does not work.
Are you debugging one of your own programs, or one that you don't have the source code for? The Visual Studio debugger isn't very friendly with regards to debugging no-source applications; in that case, I would recommend WinDbg or OllyDbg - or even skipping the debugger and write an instrumented logger using EasyHook.
EDIT:
Try setting a breakpoint at {,,kernel32.dll}_SetCurrentDirectoryA#4 - peculiar syntax and requires decorated names. Haven't tried it myself, but found it here. Google keywords: "visual studio breakpoint api" :)
You need to attach/debug the process using native code. If you by mistake are debugging using managed code you will not hit those breakpoints.
Your program may be changing directories using the msvcrt functions.
You should try placing breakpoints on these functions as well:
_chdir
_chdrive
Related
I'm building AOSP from source and have created a small C++ program that prints some messages to logcat when started. Now I wanted to debug the program according to https://source.android.com/devices/tech/debug/gdb
In the reference you're encouraged to use lldb in favor of gdb and there is also a short section on using vs code as debugger.
However, I cannot find the mentioned script lldbclient anywhere in my source nor in Android Code Search, only gdbclient.py seems to be present.
Q1: Where can I find lldbclient script?
When running the gdbclient.py script the option --setup-forwarding vscode seems to be ignored and gdb is always started.
Q2: If there isn't a lldbclient script, what options do I have to pass to gdbclient.py to enable debugging with lldb and vs code?
What did I do so far?
gdbclient.py -r /data/mysample_bin --setup-forwarding vscode
Starts my native program with attached gdb and allows me to step through my program.
Though I do not know how to code python, I was able to track down a call sequence in the script to method generate_setup_script, which is called with parameter debugger=gdb. Therefore no lldb configuration for vs code is created. Passing --no-gdb or --lldb to the script doesn't change this behavior.
Q1: You can find lldbclient.py script in the repository https://android.googlesource.com/platform/development, branch android-s-beta-2 (or another android-s branch).
Q2: Android also provides some tutorial debugging with Vscode: https://source.android.com/devices/tech/debug/gdb#vscode.
Is there a way to run my .fs file with either a breakpoint or a command like System.Diagnostics.Debugger.Launch() in it so that I can use FSI to examine values, apply functions to them, plot them, etc.?
I know this question has been asked before but I tried the answers and could not make them work. Clear instructions or a link to a write-up explaining the process would be of great help not only to myself, but also, I believe, to all beginners.
Unfortunately, you cannot hit a breakpoint and jump into FSI. The context of a running .NET program is quite different to that of an interactive FSI session and they are not compatible enough to just switch between one or the other. I can understand an expectation of this kind of debugging when coming from other dynamic/interpreted languages such as JavaScript, Python etc. It is a really powerful feature.
As you have already noted, you can use the VS immediate window but you need to use its C#-like syntax and respect its limitations. Also, since it's not F#, you need to understand the F# to .NET conversion in order to make full use of it.
If you use Paket for dependency management in your project you have another option: Add generate_load_scripts: true to your paket.dependencies. This will give you a file like .paket\load\net452\main.group.fsx, which you can load into FSI to get all of the dependencies for your project. However, you are still responsible for loading in your own source files and building up some state similar to what is found at your desired breakpoint.
To hit a break point, in visual studio or visual studio code, you just click to the left of the line number you want to set your breakpoint. This is very much a supported feature in .fs files.
I am trying to debug some problems in a native C++ COM DLL I have created and would like to launch the Visual Studio (2008) debugger from this. This dll is called by another dll that I was given, so basically my code plugs into another application through this. Anyway, in the past I had used C# to create this dll and was able to use the System.Diagnostics.Debugger.Break() method. Is there anything similar to this that can be used? I saw a few posts about DebugBreak and __debugbreak but this did not seem to work, it just appeared to stop my code from executing beyond that statement.
EDT: I followed the advice of paulsm4 below and found that the breakpoints did not work, it would tell me: "The breakpoint will not currently be hit. No Symbols have been loaded for this document"
Ideally, you'll have the project source for your COM/ActiveX .dll.
If that's the case, just set a break point in your .dll code, run your program in the debugger ... and that's it.
Please note the distinction between "managed code" (e.g. a C#/.net .exe or .dll) and "native code" (like your COM/ActiveX .dll). To debug "native code" under MSVS2008, you'll need to specify "mixed mode":
http://msdn.microsoft.com/en-us/library/kbaht4dh%28v=vs.90%29.aspx
I'm having some problems with Edit and Continue when using Visual Studio 2010 on a Windows 7 64 bit machine. I've ensured the following
Edit and Continue is enabled under Tools>Options>Debugging>Edit and Continue
My solution platform is set to x86
My solution configuration is set to Debug
All my projects are building for Debug and x86
For all projects under Projects>Properties>Build the Optimize code is unchecked
When I hit a break point and try to edit I and confronted with the following message.
(source: sedotech.com)
This is happening for me for all projects that I create whether they are WPF/Win Forms/VB.NET/C#/.NET 4/.NET 3.
Any ideas?
OK guys I figured it out. The other night I was playing around with IntelliTrace and changed the setting to collect call information. I didn't notice the warning on that page stating "Edit and continue is disabled when collecting Call Information"! See screen shot.
(source: sedotech.com)
So I just disabled that and I was good to go. Thanks, that was really annoying.
Another solution is to check if any 3rd party references included and check their options for: Embed Interop Types. Set it to False.
One more option to check to enable the Edit and Continue Option.
Go to Project Properties and check the "Enable Edit and continue" Option
I found the problem!
In Advance Compile Option (in Project Properties) Uncheck Enable Optizimations
I had that also solved it by noticing that solution configuration was on release and not debug.
Changed it to debug and now I can edit and continue.
mine was working after i have done following
under advanced compile options set target CPU to x86 (was set to any cpu)
and its working fine now.
If you want to edit code after compile.
Just compile with ctrl + F5
another reason
1-Right click on Project file then Properties.
2-Compile --> advanced compile options.
3-Choose to generate "full" instead of "pdb-only" debug info.
At the msdn site,
http://msdn.microsoft.com/en-us/library/dd264944(v=vs.100).aspx
You can read about it:
"However, collecting calls and parameters will increase performance overhead, use additional disk space, and disable the Edit and Continue feature of the Visual Studio debugger."
Under Visual Studio 2013 edit and continue now works for the x64 platform.
Under Code Generation section, make sure option "Enable Function-Level linking" is set to Yes (/Gy).
I had that also solved it by noticing that solution configuration was on AnyCPU debug and Project was x86 debug
Changed it to x86 and now I can edit and continue.
I have a solution for a unique situation.
My Edit and Continue started failing in one function in VS2013. I discovered it was because I was doing some Office Interop to Excel in that function. I moved the Interop code to its own function and Edit and Continue started working in the original function again.
I'm trying to debug a C DLL that I'm using with a Delphi program. I built the DLL with Visual C++, with debug information enabled. I built the Delphi program with Delphi 2009, with debug information enabled. But apparently they use different formats, because when I try to attach the VC++ debugger to my program, it says "binary was not built with debug information" and won't even accept as valid the breakpoints I put in the C code, which was built with debug info in the format VC++ understands.
Does anyone know how I can get this to work?
When you say "won't accept as valid" the debug breakpoints in the C code what do you mean exactly? Does it not enable them? If so has the DLL been loaded yet when you set the breakpoints? I find it can simplify matters if I wait to set the breakpoints until after I'm sure the DLL in question has been loaded. If this is not what is happening, please elaborate on what you mean by "valid" breakpoints.
Other options are to set function breakpoints, or the compile the DLL with strategically placed DebugBreak() calls.
Are you sure it's the right DLL that's being loaded (i.e. the debug version)?. Again, even the right DLL is being loaded I'm not sure the error is necessarily applying to the DLL and not just the main executable. Or it could be having problems loading the symbol database as suggested by jdigital, assuming you extract them out for debug builds of your DLL. Even with no debugging symbols, debugging should still be feasible, especially since it's a DLL, you can work from the exported symbols.
This isn't a COM component is it? If it is, I'd double check that the debug version was the one registered before you start up your process.
Again I'd still be interested in hearing exactly what happens when you try to set a break point. If you go to the breakpoints window in VS it should clarify why the breakpoint couldn't be set, if that's what is happening.
Hmm. I don't have much experience with /Z7, do you still have the .obj file for the DLL? The docs seem to imply that's necessary for debugging. Alternatively I'd try building with /Zi instead and getting a .pdb for that sucker.
Not sure about Visual C++ (don't have it installed at all anymore), but maybe this will help...
If you were writing a DLL in Delphi and using it from C++, and you wanted to debug the DLL, you'd open the source for the DLL in Delphi and set a breakpoint. You'd then use Run|Parameters and set the C++ application as the host executable and hit run in the Delphi IDE. The IDE would then launch the C++ application and run it as usual until the breakpoint in the DLL was hit, and then would break as you'd expect.
Is something similar available in VC++? (You didn't say which version of VC++, or which version of Visual Studio or the earlier IDE you were using.)
If not, the only alternative I could think of is to do a quick VC++ app that uses the DLL and debug via that instead.
Debug formats are not standardised - basically you can't use Delphi to debug MS compiled code or vice versa.
You can debug Delphi DLLs in Delphi and you can use those DLLs with other apps not compiled with Delphi, provided you mark the Delphi functions for export. What you can't do is debug those DLLs symbolically in a 3rd party debugger, which would have to understand Object Pascal name mangling at the very least.
Have you pointed the debugger at the symbols for your DLL? If there's any doubt, try running with Filemon to see if the debugger is failing when it tries to load the symbols.
Insure that is opening the DLL in the Debug Folder, not another one in some other folder.
Ten years later and this is happening to me, while debugging a custom DLL used in Team Developer, setting debugging command to start the Team Developer IDE. The objective is to step through the 3rd party code to the point of invocation of an exported function from the DLL.
Starting the debugger launches the IDE without error, but running the TD project within the TD IDE causes an exception in VS on a DLL used by the TD IDE.
How do I ignore the exceptions from outside the project? Has anyone been able to get around this since '09?