On Fri, Dec 25, 2015 at 8:57 PM, Craig Ringer <cr...@2ndquadrant.com> wrote: > On 25 December 2015 at 19:45, Michael Paquier <michael.paqu...@gmail.com> > wrote: >> >> On Thu, Dec 24, 2015 at 5:57 PM, Dave Page <dp...@pgadmin.org> wrote: >> > On Thu, Dec 24, 2015 at 2:14 AM, Craig Ringer <cr...@2ndquadrant.com> >> > wrote: >> >> On 22 December 2015 at 23:48, Alex Ignatov <a.igna...@postgrespro.ru> >> >> wrote: >> >> >> >>> >> >>> I think that you can debug crash dump since windbg exists. >> >> >> >> >> >> Nobody in their right mind uses windbg though. Visual Studio is really >> >> where >> >> it's at and the Express versions make it much more practical. >> >> Well, FWIW, I have been working lately on a bug hidden in a custom >> background worker on Windows that crashed in some weird way with a >> 0x000000C5, and while I have a reproducible test case I have not yet >> found the time to look at it yet but I would think that this is >> generating a core dump, and that I will need to use windbg for that. >> Hence count me on the -1 team. > > > Huh? > > You can use VS Express to debug a core dump. Per links upthread you can get > the platform to generate core dumps for you. No windbg required. > > If you want to torture yourself using windbg go ahead, but it really isn't > necessary, you can use a sane debugger.
Well, coming back to my story with the background worker I have been debugging. Creating PGDATA/crashdumps has allowed me to easily get a dump, and then I had a look at it using my Win7 workstation because VS was not available in the server where the crash happened, which was a 2k12 server btw. So I think that it is still useful for debugging code paths running custom code, even if we consider Postgres as rock-solid on Windows. In short, -1. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
