I use Visual Studio 2019 to write PostgreSQL extension. I get dll, put it in lib directory, .control and .sql files put in share/extensions of course. Some functions in extension crash somewhere and pgAmin4 answers me
Connection to the server has been lost
How can I debug my extension functions?
I have some experience with debugging extensions written in C but only on Linux.
The first thing that I do is to add in the code "elog" calls with some DEBUGx level to trace the code in PostgreSQL log. For example to display a character string (for this you also need to run to set client_min_messages=DEBUG1):
elog(DEBUG1,"my_extension: my_function: %s",my_string);
The second thing is to use gdb debugger that allows to debug a specific backend: on Linux you can attach a running process to gdb with its process id. but I don't know if this is possible with Windows tools.
Related
i want to do statistics on cpp programming action so i decide to develop a plugin with Visual Studio SDK. Now i encounter a problem. I want to know the running state of the cpp program. e.g. when user launch the program? when the program end? or whether the program runs successfully.
i have read a part of api references on msdn. i have just found dte.debugger and Ivsdebugger to get debug info.but i cannot find api to get normal run states.
can someone give me an idea? thank you very much.
i have solved it. in VS, debug run or normal run is treated as the same. they all trigger debug event. i can tell normal run from debug run by analysing the debug target.
My scenario is I'm supporting a VB6 app at the place I work and in the last few weeks it has started crashing more often than it ever used to. It uses both a local Access MDB database and a remote SQL Server DB for different types of storage. The good news is we are writing a replacement app, the band news I need to support this one in the meantime and the vendor is long gone from this world.
What are some ways I could try and diagnose what is causing the crash? For example so far I've tried ODBC tracing (For the MDB component), SQL Profiler tracing and ProcMon on a client PC.
Is there anything else I could try to discover what the app was trying to do at the time of the crash?
You can also start in a debugger.
windbg or ntsd (ntsd is a console program and maybe installed). Both are also from Debugging Tools For Windows.
Download and install Debugging Tools for Windows
http://msdn.microsoft.com/en-us/windows/hardware/hh852363
Install the Windows SDK but just choose the debugging tools.
Create a folder called Symbols in C:\
Start Windbg. File menu - Symbol File Path and enter
srv*C:\symbols*http://msdl.microsoft.com/download/symbols
then
windbg -o -g -G c:\windows\system32\cmd.exe /k batfile.bat
You can press F12 to stop it and kb will show the call stack (g continues the program). If there's errors it will also stop and show them.
Type lm to list loaded modules, x *!* to list the symbols and bp symbolname to set a breakpoint
Use db address (as in db 01244 to see what's at that memory.
If programming in VB6 then this environmental variable link=/pdb:none stores the symbols in the dll rather than seperate files. Make sure you compile the program with No Optimisations and tick the box for Create Symbolic Debug Info. Both on the Compile tab in the Project's Properties.
My winform application crashes as soon as its been launched. This problem is only happening in one of the client computer. Works fine for all other clients. I was thinking of using ADPlus to get a crash dump but problem is in order to configure ADPlus in crash mode, debugger need to be attached to running application first. That means application must be running when I configure ADPlus, however, as I said my application crashes as soon as I start it. It does not give me a chance to run ADPlus. Any idea if ADPlus can be used in this scenario? Are there any other tools that I can use generate a process dump in this case?
Since you can't start the program and then attach a debugger in time, you can try one of the following ideas:
Start the program under the debugger on the machine where it's crashing. As already mentioned, ProcDump is enough for that purpose, or you can use Visual Studio or WinDBG.
If you can't easily start the program under the debugger (for example, if it is actually a Windows service), use gflags to make Windows start the program under the debugger. This will create a subkey for your program filename under the Image File Execution Options registry key.
Set your debugger as the postmortem debugger, so it always launches when any program crashes.
If and when the crash happens, the debugger will automatically break in and either create a dump automatically or let you create one manually.
If you can't run a debugger, not even ProcDump, you can use Windows' built-in crash dump facility to create a dump automatically:
On Windows XP and Windows Server 2003, set Dr. Watson as the postmortem debugger by running this command:
drwtsn32 -i
Here is info on what this command does and how to use Dr. Watson: Capturing Application Crash Dumps
On Windows Vista SP1, Windows Server 2008, and later, set Windows Error Reporting to save dumps locally by creating this registry key:
HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
You don't need to create or set any values or subkeys under this key. If you want to change settings, here is more info: Collecting User-Mode Dumps
Note that "applications that do their own custom crash reporting, including .NET applications, are not supported by" WER. This is a problem for you because your app uses WinForms - although there is some indication that the feature does work with .NET 4 apps on Windows 7.
You can use ProcDump from Sysinternals to capture a dump.
Hi all I am running Visual2005 and want to generate the MAP file to analyze the
crash situation.
I have enabled below settings.
Linker->Generate MAP - Yes (/DEBUG)
General Debugging Info - Yes (/MAP)
And making the application crash by writing it in the NULL location.
If I run the EXE With VS2005 it is generating the MAP file in the path of EXE.
If I run the EXE out side the VS2005 application is crashing but no MAP file generated.
Do I need to do any other setting to generate the MAP file.
Edit: I need to analyze the crashing occuring in client location we will give them a debugg version of EXE and when it crashes they will send us the DUMP which we can analyze.
AFAIK, MAP file is created by linker and not at runtime. Do you need map file or crash dump? These are two different things.
If you want to add crash dump capability to your program, you need MiniDumpWriteDump
function and global exception handler. Then you can make post-mortem debugging, using crash dump generated by the program. See details here: http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx
Regarding map file, you only need crash address, and then you can try to find source code line by this address and map file. This technique doesn't work in many cases, post-mortem debugging is much better.
Edit. Well, you need a crash dump, this is a good decision. Using map files is not reliable. By default, Windows user mode program does not create crash dump. This feature must be added manually. CodeProject article describes how to do this, and shows how to make post-mortem debugging.
I'm using VB Express 2008. I know how to tell if code was built in debug more or release, but now I would like know how to tell if it is running in the Visual Studio IDE or not (so that I can add some debug MsgBox() and not worry about them showing if I ever accidentally ship a debug version).
Is System.Diagnostics.Debugger.IsAttached what you're looking for?
If you're building for Test and Prod, consider using a preprocessor directive in your code.
#If DEBUG Then
MsgBox("Foo")
#End If
This falls down, of course, if you ship a debug-built binary to a non-dev environment. I understand this is attacking the problem from another angle from where you asked the question (the IDE).
Try checking the IsAttached property of System.Diagnostics.Debugger
If you want to make sure you never show debug messages to users, you can use Debug.Write() and Debug.WriteLine(). These commands will output the text supplied to the debug output window. Note that you can attack a debug output window to a program running production code on a customer's machine without installing a development environment!
Testing for an attached debugger does not indicate that the debugger is also inside an IDE. It is quite common in many environments to attach debuggers to production code running on a customer system to identify what is going wrong on a particular customer's installation and usage. Testing for a debugger and then presuming you are in an IDE will foul out this usage of debuggers in a production environment.