What's the meaning of this notification? - visual-studio-2010

When I try to debug a code in Visual C++ 2010, in the Output box, there's some notification :
'latihan.exe': Loaded 'C:\Users\sinta\Documents\Visual Studio 2010\Projects\latihan\Debug\latihan.exe', Symbols loaded.
'latihan.exe': Loaded 'C:\Windows\System32\ntdll.dll', Cannot find or open the PDB file
'latihan.exe': Loaded 'C:\Windows\System32\kernel32.dll', Cannot find or open the PDB file
'latihan.exe': Loaded 'C:\Windows\System32\KernelBase.dll', Cannot find or open the PDB file
'latihan.exe': Loaded 'C:\Windows\System32\mpich2mpi.dll', Cannot find or open the PDB file
'latihan.exe': Loaded 'C:\Windows\System32\msvcr100d.dll', Symbols loaded.
The program '[1008] latihan.exe: Native' has exited with code 0 (0x0).
The code :
#include <stdio.h>
int main ()
{
printf ("Welcome \n");
return 0;
}
I just want to know, :)

Those messages mean that your system is missing the symbol files (.pdb, for program database) for various Windows DLLs. They're pretty harmless messages, since usually you won't really care about them, but if you want to get the symbols, you can obtain them via Microsoft's symbol servers.

Right-click the Output window and you'll get a context menu:
The entries with the checkboxes correspond with what you posted. They are notifications generated by the debugger when something interesting happened in your program that you might want to know about. Unchecking one stops the corresponding type of message from being displayed. Documenting them all:
Exception messages. Any exception thrown in your program produces a "First chance" exception notification message. If the exception is not caught then you'll get another one and the debugger stops at the statement that threw the exception. You are always interested in exceptions since they usually indicate a problem.
Step filtering messages. Not relevant to C++ code, managed code has a "Just My Code" debugging feature that can automatically step over code you didn't write.
Module load messages. You'll get a message for every DLL that gets loaded into your process. You got those, messages 2 through 6. It also tells you whether it could find the debugging symbols for the DLL. You don't have the ones for these Windows DLLs because you didn't configure the symbol server. You don't really need them but they can be handy when a winapi call fails.
Module unload messages. Tells you when a DLL gets unloaded
Process exit messages. Tells you when your program stopped running. The last one in your snippet. You might be interested in the exit code, 0 is good.
Thread exit messages. Tells you when a thread stopped running, also displayed with an exit code.
Program output. Anything that the code in your program writes with OutputDebugString in a C/C++ program will appear in the Output window.
Everything looks normal in your snippet.

Related

Interrupted debug at loading symbol yielded to ntdll.pdb missing

I was launching and stopping debug in visual studio really quick as I was testing something in a DLL entry point and at some point I clicked by error on "cancel" in the loading symbols window. Since then, when I launch debug, I keep having an access violation because of a "ntdll.pdb" missing.
I tried to load the symbols from Microsoft servers, but it takes ages. I would simply like to return everything back to normal, as it was before my miss-click.

What is a wil::ResultException and what does it mean to rethrow?

Using UI Automation for some Windows I get the following exceptions on a IUIAutomationElement::FindAll() call using VS2017. First question, what is a wil:ResultException and what does it mean it rethrow at memory address 0? I check the FindAll() result and doesn't seem to have FAILED(hr) because it outputs a debug message if it did and it's not.
Exception thrown at 0x00007FF897AC3E49 in app.exe: Microsoft C++ exception: wil::ResultException at memory location 0x000000550AF2BDC0.
Exception thrown at 0x00007FF897AC3E49 in app.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
I don't know if it is related or not. I turned on the fairly new "Use Text cursor indicator" as users are telling us our app can crash when it is on. After doing some testing, I was closing the app and got an access violation deep in UIAutomation.dll. The system was just exiting the process. I was trying to duplicate the crash and though I didn't crash, I just saw this same message and the reply to this post that mentioned UIAutomation. The "fairly" new setting is new to me because our IT just allowed the version update that has the setting on our boxes.
The crash occurred while doing a PeekMessage during the exit of the process. We had a static c++ object that was being deleted and during that call, it called the API. I rearranged the code to make the call that used PeekMessage so it happened before the process exited. That avoided that crash. However, we are MFC based and in a debug build, if any code does an ASSERT during shutdown, MFC's assert code does a PeekMessage to remove WM_QUIT before showing the assert message box. So, we can still crash there randomly in our debug builds.
When running with the Text Cursor Indicator on, I see a lot of these "wil" exceptions in the debug output window (release or debug builds). Many seem to occur when a window that has the indicator drawn over it closes. Example - standard file open dialog. I open it, click the path edit box and when I close the dialog, I get some of those exceptions. Turning off the indicator setting avoids all of that and the crashes.

x64dbg cannot open an exe file (but can attach it), why?

If I try to start debugging through the command "Open" of x64dbg, debugging stops without ever starting and a series of missing DLL errors are shown on the screen.
If I just open the program from WIN and THEN I use the attach command by selecting the process, debugging works.
Unfortunately I wanna "investigate" from the moment the program starts and not when it is already started.
How can I solve it ?
You need some anti-anti-debugging plugins (such as ScyllaHide) for x64dbg mentioned in this page to counter anti-debugging attempts and do some patching if needed:
https://github.com/x64dbg/x64dbg/wiki/Plugins

Visual Studio debugging program locked in memory

When i am debugging my program and an error occur, the debug session ends, but the program remains in memory. Using the activity manager of Windows to close it does not work. I need to close Visual Studio in order to kill the process.
Why is this happening?
When during debugging a program error occurs, the program usually does not "end". Instead, the debugger (VS2010) pauses execution, allowing you to inspect the code resulting in the error. Depending on the language used (e.g. C#) and the way you compiled your program, you may even be able to edit the program on the fly, move the execution cursor back a bit and continue the program from there.
If the Debug toolbar is visible (in my case it shows up automatically whenever I'm debugging), you should see a couple of "playback" buttons, allowing you to start/continue, pause, stop your program etc. If you stop your program, it will be gone from the task manager too.
As I mentioned in a comment on your question, you can also use the Debug menu to accomplish these tasks.

Follow program execution through .DLL in hex representation

Is there a way to follow a program's execution through DLL code in hex?
For example, I want to see what sections have just been read when I press a button. It has to work for x64 DLL's.
Thanks!
Yes you load the process into debugger and single step it.
Load the project in visual studio.
Press 'Play' or F5 to start the program in the debugger.
You will need to eventually halt execution sometime so you can start stepping through code or assembly code. You can do this by inserting a breakpoint, or breaking the execution by hitting the break command in the visual studio IDE.
Once halted, you can right click in the code view window, and select "Show Disassembly". Then it will show you the machine instructions.
Also in the watch window in the visual studio debugger, the right click pop up menu has an option to display all variables as hexidecimal. I'm beginning to prefer hex myself lately, because I can see invalid memory patterns easier.
You can use the tool at http://ircdb.org to log function calls arbitrary DLLs.
It's name is SocketSpy, because initially it was created for tracing winsock.dll only, but it does allow you to trace other dlls.
From http://fixunix.com/programmer/95098-tracing-library-dll-calls-win32.html
Use Option->Default Break Point List
Menu to add or remove soft breakpoints
from attached DLLs. Put soft
breakpoints only at function you need
to maximize execution time.
Soft breakpoint means that socketspy
does not stop at this breakpoint, only
log breakpoint information. Hard
breakpoint means that socketspy DOES
STOP at this breakpoint, and
Breakpoint dialog is opened. Specify
what calls should be captured ALL,
FROM EXE FILE or from DLLs (Combobox).
Specify log file File->Open Log File
menu if you want to save function
DLLs' calls into the text file, enable
logging (check box).
Then select a new or already action
process (Select Process button). The
tool can be used in NT/2000/XP only
Alternatively, there is StraceNT, which can trace arbitrary Dlls. It is available for free from http://www.intellectualheaven.com/default.asp?BH=projects&H=strace.htm
I've not used it, but I once stumble upon an Intel tool, which samples the context of the Instruction Pointer, and is able to use symbol files to convert IP to an actual function name... VTune maybe?
I guess there might be other such tools
UPDATE: aka. "statistical profilers"...
Debugging using IDE does not show you the assembly language equivalent of the execution of an IL instruction. You need to write your own hooks to a proper disassembler.

Resources