Windows 10 updates causes fork retry no child processes

Windows 10 updates causes fork retry no child processes

[Gerry Reno]

Is there some automated way I can stop Windows 10 updates from continuously causing these fork retry no child process
issues after every damn update?
We use an application based on Cygwin (2.6.0) on our clients that gets wrecked everytime a Windows 10 update occurs.
The users have no idea about Cygwin because it's hidden from them so I cannot ask them to do anything with regard to Cygwin.
.
Any ideas for an automated way to stop these errors would be appreciated.

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

Re: Windows 10 updates causes fork retry no child processes

[Evgeny Grin]

On 02.11.2016 18:47, Gerry Reno wrote:
> Is there some automated way I can stop Windows 10 updates from continuously causing these fork retry no child process
> issues after every damn update?
> We use an application based on Cygwin (2.6.0) on our clients that gets wrecked everytime a Windows 10 update occurs.
> The users have no idea about Cygwin because it's hidden from them so I cannot ask them to do anything with regard to Cygwin.
> .
> Any ideas for an automated way to stop these errors would be appreciated.

Seems that you have two options:
* Ask Microsoft to stop breaking Windows in Preview builds (according to
my personal research - Windows unloads wrong .DLL instead of requested .DLL)
* Ask your clients not to use Insider Preview because of "beta nature"
of those builds.

--
Best Wishes,
Evgeny Grin

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

Re: Windows 10 updates causes fork retry no child processes

[Gerry Reno]

On 11/02/2016 01:31 PM, Evgeny Grin wrote:
> On 02.11.2016 18:47, Gerry Reno wrote:
>> Is there some automated way I can stop Windows 10 updates from continuously causing these fork retry no child process
>> issues after every damn update?
>> We use an application based on Cygwin (2.6.0) on our clients that gets wrecked everytime a Windows 10 update occurs.
>> The users have no idea about Cygwin because it's hidden from them so I cannot ask them to do anything with regard to Cygwin.
>> .
>> Any ideas for an automated way to stop these errors would be appreciated.
> Seems that you have two options:
> * Ask Microsoft to stop breaking Windows in Preview builds (according to
> my personal research - Windows unloads wrong .DLL instead of requested .DLL)
> * Ask your clients not to use Insider Preview because of "beta nature"
> of those builds.
>
> --
> Best Wishes,
> Evgeny Grin
Thanks for trying to help.
Nobody is using Preview builds.



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

Re: Windows 10 updates causes fork retry no child processes

[Brian Inglis]

On 2016-11-02 09:47, Gerry Reno wrote:
> Is there some automated way I can stop Windows 10 updates from
> continuously causing these fork retry no child process issues after
> every damn update?
> We use an application based on Cygwin (2.6.0) on our clients that
> gets wrecked everytime a Windows 10 update occurs.
> The users have no idea about Cygwin because it's hidden from them so
> I cannot ask them to do anything with regard to Cygwin.

> Any ideas for an automated way to stop these errors would be
> appreciated.

Could be caused by changed addresses used by Windows dlls, especially
if you are using the limited address space of Cygwin32.
After each update, have you tried shutting down all Cygwin processes
and either running setup unattended, if you sometimes do that, or a
full rebase from a cmd script?
For example:
c:\cygwin64\bin\dash /bin/rebase-trigger fullrebase
c:\cygwin64\bin\ash /bin/rebaseall

You can check if an update has been performed by caching and comparing
the timestamp and/or name of the last update log saved:

$ ls -lt --time-style=long-iso \
/proc/cygdrive/c/Windows/Logs/WindowsUpdate/WindowsUpdate.20??????.??????.???.?.etl \
| head -n 1

e.g.
-rwxr-x---+ 1 SYSTEM SYSTEM  77824 2016-11-02 22:27 /proc/cygdrive/c/Windows/Logs/WindowsUpdate/WindowsUpdate.20161102.214528.076.1.etl

and checking whether a restart has been been performed since to apply
the update by comparing against the output of:

$ date -d "now - `cut -d' ' -f1 /proc/uptime` seconds" +'%F %R'

e.g.
2016-10-22 19:44

in this case indicating Windows has not been (auto)restarted since
the update.

If you don't use mintty, you could do this in an ash or dash script
at Windows login, which does the rebase-trigger then exec rebaseall,
so no other process is running using Cygwin.

If you use Cygwin mintty you would have to do the equivalent from a
cmd or PowerShell script before launching any Cygwin process.

If your client systems run Windows Enterprise or Education or use
SCCM instead of Windows Update, details may need to be changed.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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

Re: Windows 10 updates causes fork retry no child processes

[Gerry Reno]

On 11/03/2016 01:06 AM, Brian Inglis wrote:
> On 2016-11-02 09:47, Gerry Reno wrote:
>> Is there some automated way I can stop Windows 10 updates from
>> continuously causing these fork retry no child process issues after
>> every damn update?
>> We use an application based on Cygwin (2.6.0) on our clients that
>> gets wrecked everytime a Windows 10 update occurs.
>> The users have no idea about Cygwin because it's hidden from them so
>> I cannot ask them to do anything with regard to Cygwin.
>
>> Any ideas for an automated way to stop these errors would be
>> appreciated.
>
> Could be caused by changed addresses used by Windows dlls, especially
> if you are using the limited address space of Cygwin32.
> After each update, have you tried shutting down all Cygwin processes
> and either running setup unattended, if you sometimes do that, or a
> full rebase from a cmd script?
> For example:
> c:\cygwin64\bin\dash /bin/rebase-trigger fullrebase
> c:\cygwin64\bin\ash /bin/rebaseall
>
> You can check if an update has been performed by caching and comparing
> the timestamp and/or name of the last update log saved:
>
> $ ls -lt --time-style=long-iso \
> /proc/cygdrive/c/Windows/Logs/WindowsUpdate/WindowsUpdate.20??????.??????.???.?.etl \
> | head -n 1
>
> e.g.
> -rwxr-x---+ 1 SYSTEM SYSTEM  77824 2016-11-02 22:27
> /proc/cygdrive/c/Windows/Logs/WindowsUpdate/WindowsUpdate.20161102.214528.076.1.etl
>
> and checking whether a restart has been been performed since to apply
> the update by comparing against the output of:
>
> $ date -d "now - `cut -d' ' -f1 /proc/uptime` seconds" +'%F %R'
>
> e.g.
> 2016-10-22 19:44
>
> in this case indicating Windows has not been (auto)restarted since
> the update.
>
> If you don't use mintty, you could do this in an ash or dash script
> at Windows login, which does the rebase-trigger then exec rebaseall,
> so no other process is running using Cygwin.
>
> If you use Cygwin mintty you would have to do the equivalent from a
> cmd or PowerShell script before launching any Cygwin process.
>
> If your client systems run Windows Enterprise or Education or use
> SCCM instead of Windows Update, details may need to be changed.
>


The users cannot do anything with Cygwin. 
And the client machines are out in the field and not even connected to a network.
What is needed is for Cygwin itself to detect and manage the situation.


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

Re: Windows 10 updates causes fork retry no child processes

[Marco Atzeri]

On 03/11/2016 07:06, Gerry Reno wrote:

>> in this case indicating Windows has not been (auto)restarted since
>> the update.
>>
>> If you don't use mintty, you could do this in an ash or dash script
>> at Windows login, which does the rebase-trigger then exec rebaseall,
>> so no other process is running using Cygwin.
>>
>> If you use Cygwin mintty you would have to do the equivalent from a
>> cmd or PowerShell script before launching any Cygwin process.
>>
>> If your client systems run Windows Enterprise or Education or use
>> SCCM instead of Windows Update, details may need to be changed.
>>
>
>
> The users cannot do anything with Cygwin.
> And the client machines are out in the field and not even connected to a network.
> What is needed is for Cygwin itself to detect and manage the situation.
>


than it was chosen the wrong system.
Instead of W10 + Cygwin a Linux system was more indicated.

Cygwin can not avoid that other programs, poorly written,
interfere with it.
https://cygwin.com/faq/faq.html#faq.using.bloda

You need to get rid of them.

Regards
Marco








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

Re: Windows 10 updates causes fork retry no child processes

[Brian Inglis]

On 2016-11-03 00:06, Gerry Reno wrote:
> On 11/03/2016 01:06 AM, Brian Inglis wrote:
>> On 2016-11-02 09:47, Gerry Reno wrote:
>>> Is there some automated way I can stop Windows 10 updates from
>>> continuously causing these fork retry no child process issues after
>>> every damn update?
>>> We use an application based on Cygwin (2.6.0) on our clients that
>>> gets wrecked everytime a Windows 10 update occurs.
>>> The users have no idea about Cygwin because it's hidden from them so
>>> I cannot ask them to do anything with regard to Cygwin.
>>> Any ideas for an automated way to stop these errors would be
>>> appreciated.
>> Could be caused by changed addresses used by Windows dlls, especially
>> if you are using the limited address space of Cygwin32.
>> After each update, have you tried shutting down all Cygwin processes
>> and either running setup unattended, if you sometimes do that, or a
>> full rebase from a cmd script?
>> For example:
>> c:\cygwin64\bin\dash /bin/rebase-trigger fullrebase
>> c:\cygwin64\bin\ash /bin/rebaseall
>> You can check if an update has been performed by caching and comparing
>> the timestamp and/or name of the last update log saved:
>> $ ls -lt --time-style=long-iso \
>> /proc/cygdrive/c/Windows/Logs/WindowsUpdate/WindowsUpdate.20??????.??????.???.?.etl \
>> | head -n 1
>> e.g.
>> -rwxr-x---+ 1 SYSTEM SYSTEM  77824 2016-11-02 22:27
>> /proc/cygdrive/c/Windows/Logs/WindowsUpdate/WindowsUpdate.20161102.214528.076.1.etl
>> and checking whether a restart has been been performed since to apply
>> the update by comparing against the output of:
>> $ date -d "now - `cut -d' ' -f1 /proc/uptime` seconds" +'%F %R'
>> e.g.
>> 2016-10-22 19:44
>> in this case indicating Windows has not been (auto)restarted since
>> the update.
>> If you don't use mintty, you could do this in an ash or dash script
>> at Windows login, which does the rebase-trigger then exec rebaseall,
>> so no other process is running using Cygwin.
>> If you use Cygwin mintty you would have to do the equivalent from a
>> cmd or PowerShell script before launching any Cygwin process.
>> If your client systems run Windows Enterprise or Education or use
>> SCCM instead of Windows Update, details may need to be changed.
> The users cannot do anything with Cygwin.
> And the client machines are out in the field and not even connected
> to a network.
> What is needed is for Cygwin itself to detect and manage the
> situation.

Myself and others are not seeing these specific problems every update.
You may want to try following the problem reporting guidelines for help.

You need to see if you can diagnose and fix these problems in the
clients' environment by getting access and trying disabling or
deinstalling BLODAs or running rebaseall.

If you can do that, you can try patching setup, or writing scripts,
to provide a fix.

Finally, you can try submitting those patches upstream to Cygwin for
inclusion in setup, or as a separate package performing the fix.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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

Re: Windows 10 updates causes fork retry no child processes

[Gerry Reno]

On 11/03/2016 09:00 AM, Brian Inglis wrote:
> On 2016-11-03 00:06, Gerry Reno wrote:
>> On 11/03/2016 01:06 AM, Brian Inglis wrote:
>>> On 2016-11-02 09:47, Gerry Reno wrote:
>>>> Is there some automated way I can stop Windows 10 updates from
>>>> continuously causing these fork retry no child process issues after
>>>> every damn update?
>>>> We use an application based on Cygwin (2.6.0) on our clients that
>>>> gets wrecked everytime a Windows 10 update occurs.
>>>> The users have no idea about Cygwin because it's hidden from them so
>>>> I cannot ask them to do anything with regard to Cygwin.
>>>> Any ideas for an automated way to stop these errors would be
>>>> appreciated.
>>> Could be caused by changed addresses used by Windows dlls, especially
>>> if you are using the limited address space of Cygwin32.
>>> After each update, have you tried shutting down all Cygwin processes
>>> and either running setup unattended, if you sometimes do that, or a
>>> full rebase from a cmd script?
>>> For example:
>>> c:\cygwin64\bin\dash /bin/rebase-trigger fullrebase
>>> c:\cygwin64\bin\ash /bin/rebaseall
>>> You can check if an update has been performed by caching and comparing
>>> the timestamp and/or name of the last update log saved:
>>> $ ls -lt --time-style=long-iso \
>>> /proc/cygdrive/c/Windows/Logs/WindowsUpdate/WindowsUpdate.20??????.??????.???.?.etl \
>>> | head -n 1
>>> e.g.
>>> -rwxr-x---+ 1 SYSTEM SYSTEM  77824 2016-11-02 22:27
>>> /proc/cygdrive/c/Windows/Logs/WindowsUpdate/WindowsUpdate.20161102.214528.076.1.etl
>>> and checking whether a restart has been been performed since to apply
>>> the update by comparing against the output of:
>>> $ date -d "now - `cut -d' ' -f1 /proc/uptime` seconds" +'%F %R'
>>> e.g.
>>> 2016-10-22 19:44
>>> in this case indicating Windows has not been (auto)restarted since
>>> the update.
>>> If you don't use mintty, you could do this in an ash or dash script
>>> at Windows login, which does the rebase-trigger then exec rebaseall,
>>> so no other process is running using Cygwin.
>>> If you use Cygwin mintty you would have to do the equivalent from a
>>> cmd or PowerShell script before launching any Cygwin process.
>>> If your client systems run Windows Enterprise or Education or use
>>> SCCM instead of Windows Update, details may need to be changed.
>> The users cannot do anything with Cygwin.
>> And the client machines are out in the field and not even connected
>> to a network.
>> What is needed is for Cygwin itself to detect and manage the
>> situation.
>
> Myself and others are not seeing these specific problems every update.
> You may want to try following the problem reporting guidelines for help.
>
> You need to see if you can diagnose and fix these problems in the
> clients' environment by getting access and trying disabling or
> deinstalling BLODAs or running rebaseall.
>
> If you can do that, you can try patching setup, or writing scripts,
> to provide a fix.
>
> Finally, you can try submitting those patches upstream to Cygwin for
> inclusion in setup, or as a separate package performing the fix.
>

We are only seeing this on the newer W10 machines.
W8 machines don't exhibit this problem.
And both have the exact same set of software installed on them.
So there must be something different about W10.


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

Re: Windows 10 updates causes fork retry no child processes

[Eliot Moss]

On 11/3/2016 9:42 AM, Gerry Reno wrote:

> We are only seeing this on the newer W10 machines.
> W8 machines don't exhibit this problem.
> And both have the exact same set of software installed on them.
> So there must be something different about W10.

Windows 10 is definitely aggressive about forcing reboots
after updates.  I've not yet found an effective way to
turn it off so that I can do it at a more convenient
future time.

This changed some (harder to turn off auto-restart)
with W 10 Anniversary Edition.

Regards - Eliot Moss

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

Re: Windows 10 updates causes fork retry no child processes

[Brian Inglis]

On 2016-11-03 07:46, Eliot Moss wrote:
> On 11/3/2016 9:42 AM, Gerry Reno wrote:
>
>> We are only seeing this on the newer W10 machines.
>> W8 machines don't exhibit this problem.
>> And both have the exact same set of software installed on them.
>> So there must be something different about W10.
> Windows 10 is definitely aggressive about forcing reboots
> after updates.  I've not yet found an effective way to
> turn it off so that I can do it at a more convenient
> future time.

Some control is possible with Settings/Updates & Security/
Windows Update/Active hours.
Only allows contiguous 12 within 24 hours (no wraparound
across midnight) for people who waste the night sleeping ;^>
Setting this seems to defer restarts up to a week.
On W10 Pro, you can choose 16?/18? hours apparently.

It also features terrible graphics hours and minutes "spinner"
like old mechanical rotary clocks and calendars - ugh ;^p
*Might* be acceptable on some school kid's project, but most of
them have more design sense, standards, and taste, than MicroSoft.
Would be nice to shrink these tabletized wastes of screen real
estate with huge fonts to normal dialogue box forms.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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

Re: Windows 10 updates causes fork retry no child processes

[Hans-Bernhard Bröker]

Am 03.11.2016 um 07:06 schrieb Gerry Reno:

> And the client machines are out in the field and not even connected to a network.

If so, how/why do they ever hear about Windows updates in the first place?

> What is needed is for Cygwin itself to detect and manage the situation.

That is technically impossible.  The DLL rebasing procedure can only be 
done from _outside_ Cygwin.

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

Re: Windows 10 updates causes fork retry no child processes

[Gerry Reno]

On 11/03/2016 10:31 AM, Hans-Bernhard Bröker wrote:
> Am 03.11.2016 um 07:06 schrieb Gerry Reno:
>
>> And the client machines are out in the field and not even connected to a network.
>
> If so, how/why do they ever hear about Windows updates in the first place?
>
>> What is needed is for Cygwin itself to detect and manage the situation.
>
> That is technically impossible.  The DLL rebasing procedure can only be done from _outside_ Cygwin.
>

They aren't connected permanently to an office network. 
They can connect to WiFi every so often when they get near to a WiFi location.

Ok, so why is automating this DLL rebasing procedure impossible?
I don't care if it is a Cygwin process or a Windows process that does this.
Something needs to check to see if the DLL rebasing needs done and then do it if that is the source of the problem.

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

Re: Windows 10 updates causes fork retry no child processes

[Brian Inglis]

On 2016-11-03 08:58, Gerry Reno wrote:
> On 11/03/2016 10:31 AM, Hans-Bernhard Bröker wrote:
>> Am 03.11.2016 um 07:06 schrieb Gerry Reno:
>>> And the client machines are out in the field and not even
>>> connected to a network.
>> If so, how/why do they ever hear about Windows updates in the first
>> place?
>>> What is needed is for Cygwin itself to detect and manage the
>>> situation.
>> That is technically impossible. The DLL rebasing procedure can only
>> be done from _outside_ Cygwin.
> They aren't connected permanently to an office network.
> They can connect to WiFi every so often when they get near to a WiFi
> location.  
> Ok, so why is automating this DLL rebasing procedure impossible?
> I don't care if it is a Cygwin process or a Windows process that does
> this.
> Something needs to check to see if the DLL rebasing needs done and
> then do it if that is the source of the problem.

Maybe your clients' problem is that W10 is now dynamically loading wifi
or network dlls into the stack and being a total BLODA?
Your app setup, your clients, so *you* need to do the data collection
and diagnosis, ask for help here, test fixes.
At least a cygcheck -rsv from a problem system, attached to a post,
would let the dogs here see the shape of the bone to help you.

As with other off-net systems, there should be some auto-reporting
system built in where you can capture and send problem logs.
Maybe you could change the env setting for:
CYGWIN=error_start=C:/cygwin64/bin/dumper
(use slashes instead of doubled backslashes)
to run cygcheck -hrsv > cygcheck.txt instead, perhaps from a cmd
script, and queue it for mailing to you when connected?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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

Re: Windows 10 updates causes fork retry no child processes

[Gerry Reno]

On 11/03/2016 01:28 PM, Brian Inglis wrote:
> On 2016-11-03 08:58, Gerry Reno wrote:
>> On 11/03/2016 10:31 AM, Hans-Bernhard Bröker wrote:
>>> Am 03.11.2016 um 07:06 schrieb Gerry Reno:
>>>> And the client machines are out in the field and not even
>>>> connected to a network.
>>> If so, how/why do they ever hear about Windows updates in the first
>>> place?
>>>> What is needed is for Cygwin itself to detect and manage the
>>>> situation.
>>> That is technically impossible. The DLL rebasing procedure can only
>>> be done from _outside_ Cygwin.
>> They aren't connected permanently to an office network.
>> They can connect to WiFi every so often when they get near to a WiFi
>> location.  Ok, so why is automating this DLL rebasing procedure impossible?
>> I don't care if it is a Cygwin process or a Windows process that does
>> this.
>> Something needs to check to see if the DLL rebasing needs done and
>> then do it if that is the source of the problem.
>
> Maybe your clients' problem is that W10 is now dynamically loading wifi
> or network dlls into the stack and being a total BLODA?
> Your app setup, your clients, so *you* need to do the data collection
> and diagnosis, ask for help here, test fixes.
> At least a cygcheck -rsv from a problem system, attached to a post,
> would let the dogs here see the shape of the bone to help you.
>
> As with other off-net systems, there should be some auto-reporting
> system built in where you can capture and send problem logs.
> Maybe you could change the env setting for:
> CYGWIN=error_start=C:/cygwin64/bin/dumper
> (use slashes instead of doubled backslashes)
> to run cygcheck -hrsv > cygcheck.txt instead, perhaps from a cmd
> script, and queue it for mailing to you when connected? I th
>

I think the simplest way for right now might be to have a batch file run at startup that runs rebaseall.

Something like these lines in a batch file:
cd C:\Cygwin\bin
.\ash /bin/rebaseall

This would rebase the dlls each time after Windows Update forces a reboot.

Do you see any issue with that?



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

Re: Windows 10 updates causes fork retry no child processes

[Achim Gratz]

Gerry Reno writes:
> I think the simplest way for right now might be to have a batch file
> run at startup that runs rebaseall.
>
> Something like these lines in a batch file:
> cd C:\Cygwin\bin
> .\ash /bin/rebaseall
>
> This would rebase the dlls each time after Windows Update forces a reboot.
>
> Do you see any issue with that?

You are barking up the wrong tree.  If the Cygwin installation is
unchanged (as you said it is), then each rebaseall will result in
exactly the same base addresses for the DLL as before.  So yes, you
could do what you say (provided that you didn't start any services that
start Cygwin processes), but it wouldn't help anything.

If your Cygwin installation is too big to fit into the address space
(likely if it's a 32bit installation and you installed everything), then
you need to trim it down.  If it's a 32bit Windows, you'll also need to
switch to a 3GB user VM so the heap gets moved above 2GB.  If it's
BLODA, you need to stop using it or configure it to stay out of Cygwin's
business.  The thing that _does_ change each reboot is that any DLL
using ASLR will end up in a different place until the next reboot, so
unless you check which DLL you collide with (if it is indeed a collision
and not an intercept), you'll always get a different Cygwin DLL name
presented.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

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

Re: Windows 10 updates causes fork retry no child processes

[Gerry Reno]

On 11/03/2016 02:47 PM, Achim Gratz wrote:
> Gerry Reno writes:
>> I think the simplest way for right now might be to have a batch file
>> run at startup that runs rebaseall.
>>
>> Something like these lines in a batch file:
>> cd C:\Cygwin\bin
>> .\ash /bin/rebaseall
>>
>> This would rebase the dlls each time after Windows Update forces a reboot.
>>
>> Do you see any issue with that?
> You are barking up the wrong tree.  If the Cygwin installation is
> unchanged (as you said it is), then each rebaseall will result in
> exactly the same base addresses for the DLL as before.  So yes, you
> could do what you say (provided that you didn't start any services that
> start Cygwin processes), but it wouldn't help anything.
>
> If your Cygwin installation is too big to fit into the address space
> (likely if it's a 32bit installation and you installed everything), then
> you need to trim it down.  If it's a 32bit Windows, you'll also need to
> switch to a 3GB user VM so the heap gets moved above 2GB.  If it's
> BLODA, you need to stop using it or configure it to stay out of Cygwin's
> business.  The thing that _does_ change each reboot is that any DLL
> using ASLR will end up in a different place until the next reboot, so
> unless you check which DLL you collide with (if it is indeed a collision
> and not an intercept), you'll always get a different Cygwin DLL name
> presented.
>
>
> Regards,
> Achim.

The installation and applications are 32-bit that we've used for years.
The installation is very trimmed down, it is not an "everything" install.

How do I switch them to a 3GB user VM?

The W10 users can clear the problem if they wait some number of minutes and keep rebooting their machines.
Eventually after a while most of them get the problem to clear but this is a RPITA and it frustrates them no end.
One W10 user seems unable to clear their problem and we keep uninstalling and reinstalling everything for them.








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

Re: Windows 10 updates causes fork retry no child processes

[Achim Gratz]

Gerry Reno writes:
> The installation and applications are 32-bit that we've used for
> years.  The installation is very trimmed down, it is not an
> "everything" install.

Maybe if you'd take the hint about following proper problem reporting that
others have made repeatedly…

> How do I switch them to a 3GB user VM?

With bcdedit, the variable to change is "/uservm=3072" (standard is
2048).  There's a TN article about it.

> The W10 users can clear the problem if they wait some number of
> minutes and keep rebooting their machines.  Eventually after a while
> most of them get the problem to clear but this is a RPITA and it
> frustrates them no end.  One W10 user seems unable to clear their
> problem and we keep uninstalling and reinstalling everything for them.

The problem is quite unlikely to be Cygwin then (and also not the
Windows update), but some other program that maps into the same address
space (most likely one that is using ASLR, which would explain why the
problem can be mitigated by multiple reboots).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

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

Re: Windows 10 updates causes fork retry no child processes

[Brian Inglis]

On 2016-11-03 12:32, Gerry Reno wrote:
> On 11/03/2016 01:28 PM, Brian Inglis wrote:
>> On 2016-11-03 08:58, Gerry Reno wrote:
>>> On 11/03/2016 10:31 AM, Hans-Bernhard Bröker wrote:
>>>> Am 03.11.2016 um 07:06 schrieb Gerry Reno:
>>>>> And the client machines are out in the field and not even
>>>>> connected to a network.
>>>> If so, how/why do they ever hear about Windows updates in the first
>>>> place?
>>>>> What is needed is for Cygwin itself to detect and manage the
>>>>> situation.
>>>> That is technically impossible. The DLL rebasing procedure can only
>>>> be done from _outside_ Cygwin.
>>> They aren't connected permanently to an office network.
>>> They can connect to WiFi every so often when they get near to a WiFi
>>> location.  Ok, so why is automating this DLL rebasing procedure impossible?
>>> I don't care if it is a Cygwin process or a Windows process that does
>>> this.
>>> Something needs to check to see if the DLL rebasing needs done and
>>> then do it if that is the source of the problem.
>>
>> Maybe your clients' problem is that W10 is now dynamically loading wifi
>> or network dlls into the stack and being a total BLODA?
>> Your app setup, your clients, so *you* need to do the data collection
>> and diagnosis, ask for help here, test fixes.
>> At least a cygcheck -rsv from a problem system, attached to a post,
>> would let the dogs here see the shape of the bone to help you.
>>
>> As with other off-net systems, there should be some auto-reporting
>> system built in where you can capture and send problem logs.
>> Maybe you could change the env setting for:
>> CYGWIN=error_start=C:/cygwin64/bin/dumper
>> (use slashes instead of doubled backslashes)
>> to run cygcheck -hrsv > cygcheck.txt instead, perhaps from a cmd
>> script, and queue it for mailing to you when connected? I th
>>
>
> I think the simplest way for right now might be to have a batch file run at startup that runs rebaseall.
>
> Something like these lines in a batch file:
> cd C:\Cygwin\bin
> .\ash /bin/rebaseall
>
> This would rebase the dlls each time after Windows Update forces a reboot.
>
> Do you see any issue with that?

To set up for a full rebase you need to run the following first:

.\dash /bin/rebase-trigger fullrebase

otherwise it will run an incremental and probably do nothing.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

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

Re: Windows 10 updates causes fork retry no child processes

[Gerry Reno]

On 11/03/2016 06:08 PM, Brian Inglis wrote:
> On 2016-11-03 12:32, Gerry Reno wrote:
>> On 11/03/2016 01:28 PM, Brian Inglis wrote:
>>> On 2016-11-03 08:58, Gerry Reno wrote:
>>>> On 11/03/2016 10:31 AM, Hans-Bernhard Bröker wrote:
>>>>> Am 03.11.2016 um 07:06 schrieb Gerry Reno:
>>>>>> And the client machines are out in the field and not even
>>>>>> connected to a network.
>>>>> If so, how/why do they ever hear about Windows updates in the first
>>>>> place?
>>>>>> What is needed is for Cygwin itself to detect and manage the
>>>>>> situation.
>>>>> That is technically impossible. The DLL rebasing procedure can only
>>>>> be done from _outside_ Cygwin.
>>>> They aren't connected permanently to an office network.
>>>> They can connect to WiFi every so often when they get near to a WiFi
>>>> location.  Ok, so why is automating this DLL rebasing procedure impossible?
>>>> I don't care if it is a Cygwin process or a Windows process that does
>>>> this.
>>>> Something needs to check to see if the DLL rebasing needs done and
>>>> then do it if that is the source of the problem.
>>>
>>> Maybe your clients' problem is that W10 is now dynamically loading wifi
>>> or network dlls into the stack and being a total BLODA?
>>> Your app setup, your clients, so *you* need to do the data collection
>>> and diagnosis, ask for help here, test fixes.
>>> At least a cygcheck -rsv from a problem system, attached to a post,
>>> would let the dogs here see the shape of the bone to help you.
>>>
>>> As with other off-net systems, there should be some auto-reporting
>>> system built in where you can capture and send problem logs.
>>> Maybe you could change the env setting for:
>>> CYGWIN=error_start=C:/cygwin64/bin/dumper
>>> (use slashes instead of doubled backslashes)
>>> to run cygcheck -hrsv > cygcheck.txt instead, perhaps from a cmd
>>> script, and queue it for mailing to you when connected? I th
>>>
>>
>> I think the simplest way for right now might be to have a batch file run at startup that runs rebaseall.
>>
>> Something like these lines in a batch file:
>> cd C:\Cygwin\bin
>> .\ash /bin/rebaseall
>>
>> This would rebase the dlls each time after Windows Update forces a reboot.
>>
>> Do you see any issue with that?
>
> To set up for a full rebase you need to run the following first:
>
> .\dash /bin/rebase-trigger fullrebase
>
> otherwise it will run an incremental and probably do nothing.
>

Ok, thanks.
Got a few things to try from everyone's suggestions as soon as I can get ahold of one of these problem W10 machines.



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

Re: Windows 10 updates causes fork retry no child processes

[Achim Gratz]

Brian Inglis writes:
>> I think the simplest way for right now might be to have a batch file run at startup that runs rebaseall.
>>
>> Something like these lines in a batch file:
>> cd C:\Cygwin\bin
>> .\ash /bin/rebaseall
>>
>> This would rebase the dlls each time after Windows Update forces a reboot.
>>
>> Do you see any issue with that?
>
> To set up for a full rebase you need to run the following first:
>
> .\dash /bin/rebase-trigger fullrebase
>
> otherwise it will run an incremental and probably do nothing.

No, rebaseall is distinct from the incremental autorebase script.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

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

Re: Windows 10 updates causes fork retry no child processes

[Gerry Reno]

On 11/04/2016 02:40 PM, Achim Gratz wrote:
> Brian Inglis writes:
>>> I think the simplest way for right now might be to have a batch file run at startup that runs rebaseall.
>>>
>>> Something like these lines in a batch file:
>>> cd C:\Cygwin\bin
>>> .\ash /bin/rebaseall
>>>
>>> This would rebase the dlls each time after Windows Update forces a reboot.
>>>
>>> Do you see any issue with that?
>> To set up for a full rebase you need to run the following first:
>>
>> .\dash /bin/rebase-trigger fullrebase
>>
>> otherwise it will run an incremental and probably do nothing.
> No, rebaseall is distinct from the incremental autorebase script.
>
>
> Regards,
> Achim.

Thanks for the clarification.


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

Re: Windows 10 updates causes fork retry no child processes

[L. A. Walsh]

Hans-Bernhard Bröker wrote:
> Am 03.11.2016 um 07:06 schrieb Gerry Reno:
>> What is needed is for Cygwin itself to detect and manage the situation.
> 
> That is technically impossible.  The DLL rebasing procedure can only be 
> done from _outside_ Cygwin.
---
	Oh?
	The Dll rebasing needs to be done outside of the hosted
cygwin environment, which is not to say that dll rebasing is done
outside of cygwin.  I don't know about now, but everything to do
dll-rebasing was part of cygwin -- just not the hosted environment
part of it.  

	For example "setup.exe" is part of the cygwin project,
but not part of the hosted environment, so it can replace dll's
that are part of the hosted environment (or tell you that you
will need to reboot).

	None of the above discussion over terminology should
be taken to mean that I believe cygwin should constantly try
to repair actively changing damage done by win10.  
	

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

Re: Windows 10 updates causes fork retry no child processes

[Marko Božiković]

On 02/11/2016 15:47, Gerry Reno wrote:
> Is there some automated way I can stop Windows 10 updates from continuously causing these fork retry no child process
> issues after every damn update?
> We use an application based on Cygwin (2.6.0) on our clients that gets wrecked everytime a Windows 10 update occurs.
> The users have no idea about Cygwin because it's hidden from them so I cannot ask them to do anything with regard to Cygwin.
> .
> Any ideas for an automated way to stop these errors would be appreciated.

If your clients are using Win10 Pro, you can still disable automatic update
download and install using Group Policy. Would that work for your scenario?

-- 
Marko


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