Urgh! Hmm.. Do you see the same effect when running the process in
question under the Windows 8 operating system context?
If you manifest and include:
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!--The ID below indicates application support for Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!--The ID below indicates application support for Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!--The ID below indicates application support for Windows 8 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
</application>
</compatibility>
http://msdn.microsoft.com/en-us/library/windows/desktop/hh848036(v=vs.85).aspx
Does the odd behaviour still persist?
Could it be possibly be something to do with the fault tolerant heap
(FTH) and changes they've made to it? I would try ensuring that is
switched off too...
(Process Hacker will show the context of a running process.)
Nick
> Thanks. I can confirm the effect. For no apparent reason, the OS
> reserves a 1 Megs shared memory region, top-down allocated, of which it
> uses about 20K. It's not the PEB or one of the TEBs, though. Nor is
> it a thread stack. I checked, and it turns out that it's allocated
> in every process, on 32 and 64 bit systems. That's kind of worrying
> since that's bound to collide with mmaped regions and pthread stacks a
> lot. I don't know what to do at this point.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
