On Fri, Dec 25, 2015 at 8:57 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
> On 25 December 2015 at 19:45, Michael Paquier <michael.paquier@gmail.com>
> wrote:
>>
>> On Thu, Dec 24, 2015 at 5:57 PM, Dave Page <dpage@pgadmin.org> wrote:
>> > On Thu, Dec 24, 2015 at 2:14 AM, Craig Ringer <craig@2ndquadrant.com>
>> > wrote:
>> >> On 22 December 2015 at 23:48, Alex Ignatov <a.ignatov@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
