Thread: 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