Обсуждение: PostgreSQL and Windows 10 exception 0xC0000018

Hi all,<br />     a strange error is happening to some of our customers.<br /> They all have a Windows 10 installation
ontheir machines with our application and, of course, PostgreSQL 9.1 installed (migration to 9.5 upcoming in late
summer/fall,but not applicable by now)<br /><br /> While working, suddenly PostgreSQL stops working, and log reports<br
/><br/> 2016-05-05 10:36:19 CEST LOG:  server process (PID 5920) was terminated by exception 0xC0000018<br />
2016-05-0510:36:19 CEST HINT:  See C include file "ntstatus.h" for a description of the hexadecimal value.<br />
2016-05-0510:36:19 CEST LOG:  terminating any other active server processes<br /> 2016-05-05 10:36:19 CEST WARNING: 
terminatingconnection because of crash of another server process<br /> 2016-05-05 10:36:19 CEST DETAIL:  The postmaster
hascommanded this server process to roll back the current transaction and exit, because another server process exited
abnormallyand possibly corrupted shared memory.<br /> 2016-05-05 10:36:19 CEST HINT:  In a moment you should be able to
reconnectto the database and repeat your command.<br /> [... above three lines repeated a bunch of times...]<br />
2016-05-0510:36:19 CEST LOG:  all server processes terminated; reinitializing<br /> 2016-05-05 10:36:29 CEST FATAL: 
pre-existingshared memory block is still in use<br /> 2016-05-05 10:36:29 CEST HINT:  Check if there are any old server
processesstill running, and terminate them.<br /><br /> ntstatus.h refers to exception code as<br
/><p><i>0xC0000018</i><i></i><p><i>STATUS_CONFLICTING_ADDRESSES</i><i> </i><p><i>{Conflicting Address Range} The
specifiedaddress range conflicts with the address space.</i> Googling I found many applications failing with that error
andhow to fix them by setting a value in Registry, but these are not the cases.<br /> All I found in common of these
machines(except Windows 10 and our app :-) ) was ClassicShell. Uninstalling it seemed to resolve the problem... until 2
hoursago, when one of them submitted us the same crash with same error.<br /><br /> Trying to google deeper did not
helpfor me.<br /><br /> This issue seems to be present on Windows 10 machines.<br /><br /> Any
idea/thought/suggestion?<br/><br /> Thanks in advance,<br /> Moreno.-<br /> 

Disclaimer: I do not run Postgresql on Windows.

On Thu, 5 May 2016 14:39:25 +0200, Moreno Andreo
<moreno.andreo@evolu-s.it> wrote:

>    a strange error is happening to some of our customers.
>They all have a Windows 10 installation on their machines with
>our application and, of course, PostgreSQL 9.1 installed
>(migration to 9.5 upcoming in late summer/fall, but not applicable
>by now)
>
>    :
>
>0xC0000018
>
>STATUS_CONFLICTING_ADDRESSES
>
>{Conflicting Address Range} The specified address range conflicts
>with the address space. Googling I found many applications failing
>with that error and how to fix them by setting a value in Registry,
>but these are not the cases.
>All I found in common of these machines (except Windows 10 and
>our app :-) ) was ClassicShell. Uninstalling it seemed to resolve the
>problem... until 2 hours ago, when one of them submitted us the
>same crash with same error.
>
>Trying to google deeper did not help for me.
>
>This issue seems to be present on Windows 10 machines.
>
>Any idea/thought/suggestion?

It's a code address conflict.  It's normally caused by trying to load
more than one fixed base DLL at the same address in the same process.

Typically DLLs have a preferred base address, but are relocatable if
that address is already occupied.  DLLs with fixed base addresses
cannot be relocated (the necessary meta-information is not in the
executable).


It is known to have been caused by McAffee and MalwareBytes
Anti-Exploit.  If either of those are installed, they may need to be
updated.


Otherwise: if Postgresql is loading any non-standard extensions, I
would try to check those DLLs.  If you have a recent Visual Studio
handy, run "link /dump /headers <file>" on the DLLs and look for any
that say "fixed base" under "DLL characteristics".   If you find more
than one that have the same "image base" address, then you've got a
problem.

If you don't find anything, then I would guess 9.1 is just too old.

Hope this helps,
George

On 5/5/2016 1:17 PM, Moreno Andreo wrote:
> Il 05/05/2016 18:40, George Neuner ha scritto:
>> Otherwise: if Postgresql is loading any non-standard extensions, I
>> would try to check those DLLs.  If you have a recent Visual Studio
>> handy, run "link /dump /headers <file>" on the DLLs and look for any
>> that say "fixed base" under "DLL characteristics".   If you find more
>> than one that have the same "image base" address, then you've got a
>> problem.
> No extensions here, but I'll give a try. Since I have to do this on
> customer box (without VS) I'll try and find a "smaller package" than a
> VS install...
> In this cases it's better to try everything that makes sense... :-)

There's a free utility called "wumpbin"
(http://www.benf.org/other/wumpbin/) which claims to be a clone of VS
dumpbin.exe.  AFAICT it works on Win7, but I don't have Win10 available
to try it there.  And I can't vouch for its accuracy - I have only toyed
with it.

dumpbin itself appears to be deprecated.  It's still in VS and it still
works, but  "link /dump ..." is now the preferred method.

George