I try to send debug mesage with OutputDebugString function. I use this function in my dll project and i get this message in DebugView. I also use this function in my console app project(same solution) but i can't get messages. All messages appear in the DebugView except for the console application. It does not even appear the simple OutputDebugStringA("debug"); or OutputDebugString(L"debug"); codes. What could it cause?
One issue is that whether you visit it in your VS output window or the tool DebugView here: https://technet.microsoft.com/en-us/sysinternals/bb896647?f=255&MSPPError=-2147217396. They are different.
If you use the Debug view, not debug your app, just run it using "start without debugging(Ctrl+F5)".
If you use the VS output window and other apps output normally, just the specific console app has this issue, I don't think it is related to the debugger tool, we would think about the project itself or VS Settings.
(1)Please set a breakpoint in the code line "OutputDebugString(L"debug");", and then debug your app using "F5", after the breakpoint was hit, click "Step Into (F11)", and then visit your debug output window. Maybe the specific line code was not called in your side.
(2)Since there are different projects in the same solution, please set this console app as the start up project. Or you could just create a single solution for this project, debug it again. At least, we could know that whether other projects impact this specific console app.
(3) Just test it in other VS IDE, make sure that it is not the VS IDE issue. I just use the default VS settings in my side, it works well.
Reference:
https://blogs.msdn.microsoft.com/reiley/2011/07/29/a-debugging-approach-to-outputdebugstring/
Related
I've used Visual Studio 2017 to create a queue triggered Azure Function. All that the default generated code does is write a message to the log. The code works, but if you set a breakpoint on it, it is ignored by the debugger.
I have same problem with another queue triggered function that has more complex code, but I created this one as a very simple test case.
What do you have to do to get debug breakpoints to work on this type of project?
Answer was found here which is:
(1) right click your project and go to properties page
(2) select "Build" on left
(3) click "Advanced..." button
(4) change "Debugging information" to "Full"
As stupid as it sounds, I managed to make it work by unchecking the option
Automatically close the console when debugging stops
in Tools > Options > Debugging > General
I am currently working on a project that relies on injecting a DLL into another process, so (AFAICT) standard debugging tools don't work. What I've been using instead is #define DEBUG(_msg) MessageBoxA(nullptr, _msg, "Debug", MB_OK).
This has the issue that it blocks the current thread until I click on the message box, which screws up my code in certain places and/or freezes the process I injected the DLL into.
So, how should I print a debug message with the Win32 API that I can view elsewhere, and continue running code instantly?
In Visual Studio a running process can be debugged.
In the menu Debug look for Attach to process.
Then breakpoints can be triggered like normal.
I have configured my windows 7 to create mini dump files on crashes but when my application crashed, no dump file was created. The search for answer left me rather confused as to when are dump files created, when windows crashes or my application crashes?
In my case, I am looking for dump file when my application crashes. I receive a typical crash dialog that states:
TheApp Application has stopped working
Windows can check online for a solution to the problem
-> Check online for a solution and close the program
-> Close the program
-> Debug the program
So can I generate dump file for my application when it crashes? I can't produce this bug on development machine so I want to walk back from dump file. Is there any other option to trace the source of bug (to source code)?
First of all, there are different places to configure a "create a minidump on crash" setting, which are totally different.
You can configure Windows to create a kernel dump file when Windows crashes, i.e. when a Bluescreen of death (BSOD) occurs. This is done in the following screen on Windows 7:
You can configure Windows to create a user mode dump file when an application crashes, i.e. instead of the "Windows Error Reporting" dialog which would normally appear. To do so, and you know that in advance, then configure a Registry key called LocalDumps (MSDN). By default, dumps will be created below %LOCALAPPDATA%\CrashDumps and they will have the naming scheme app.exe.<PID>.dmp.
For the sake of completeness, there might be other triggers. The only sure way to tell is: when the method MiniDumpWriteDump (MSDN) is called.
I'm quite sure that you want option 2 of the above. If you have trouble with it, see whether all the conditions for LocalDump are fulfilled.
The answer given by #antlersoft does not work, for the reasons I have posted in my blog: at the time the dialog is shown, Windows has triggered a breakpoint to stop the application and it has injected a callstack of Windows Error Reporting. All in all, not a good starting point for debugging.
What would work is:
attach a debugger of your choice
press "Go" in the debugger
press the "Debug" button of the WER dialog
confirm the warning about the debugger which is already attached
click "No" when asked to start debugging using the selected debugger
Using Task Manager to create a crash dump is not recommended, since it will not consider the bitness of the application, which may cause trouble later. See ways to create good and useful crash dumps.
Minidump is created when Windows crashes. It's not intended to application crash.
If you want to debug crashes of your application, you may attach it to a debugger after it is started. Clicking on the "Debug" button when application crashes do the same. You can use the debugger of MS Visual Studio to do that, for example.
See this page for help on attaching a process to MS Visual Studio debugger:
https://msdn.microsoft.com/en-us/library/3s68z0b3.aspx
EDIT: following text removed, as this may not work as expected (comment from Thomas)
You can also create a dump file from task manager, however you will still need a debugger to analyze it and, actually I am not sure you will be able to get the dump file at the point application crashes. The best way, if you can, is to debug the process on the target machine by attaching it to debugger either after it is started or when crash occurs.
When you get the crash dialog, go to Task Manager, find the process, right click on the process, and select "Create dump file". The dump file is created in the AppData/Local/Temp folder for the user; it will be named %AppData%\Local\Temp\.DMP; if you create multiple it will be -1.DMP, etc. You can move the dump file to your development machine and open it within Visual Studio. Visual Studio will then act as if you had hit "Break all" at the point of the crash while running the process in the debugger.
I am trying to dissect a legacy application through debugging, but I can't get the breakpoint to hit in certain places of the application. The application has a c# GUI frontend and a c++ backend.
I am trying to put a breakpoint in a c++ project of the solution. There are a couple of c++ projects, but I cannot set a breakpoint in one of them. I tried deleting bin/obj files but had no luck.
Afterwards I checked debug > windows > modules, and then noticed that the dll for that particular project is not being shown. The program executes correctly, but perhaps since there is no entry for that project shown in debug > windows > modules, a breakpoint cannot be set. The problem is, I don't know how to make a fix to this problem. Can anyone give a helping hand?
Thanks a lot in advance.
It sounds like you need to enable unmanaged code debugging. Try the follownig
Right click on the C# project and select Properties
Go to the Debug tab
Check "Enable Unmanaged Code Debugging"
Using VS .NET 2003. Would like to run the .exe from outside the IDE (i.e. command prompt or double clicking .exe icon in windows) However, still want break points to hit in the IDE.
How do I set this up?
(Running from outside IDE but IDE seeing it as run from "Debug" -> "Start")
Thanks.
On the Debug menu, choose the "Attach to process" option to attach a debugger to your externally-running application.
Visual Studio enables Just In Time Debugging by default. If you haven't turned it off you can call DebugBreak() and you will get a popup allowing you to attach a debugger. If you don't attach a debugger then the program will exit, so you could try wrapping the DebugBreak call in a MessageBox or some other conditional code based on an environment variable or config item.
Since it is C the call to DebugBreak() is correct - this will give you a nasty error dialog (different look depending on the OS), which should have a 'Debug' option. If you click this you should get a dialog to select one of the installed debuggers (VS.NET shoud be among them). Selecting it should bring you to the DebugBreak() line. However this can fail if the debugger can not find the pdb files for your app - in that case you will just get the disassembly view and no source code view.
You can also use WinDBG and the 'Open executable option' - again it will need the pdb files to yield anything useful.