* Windows 10 updates causes fork retry no child processes @ 2016-11-02 15:47 Gerry Reno 2016-11-02 17:31 ` Evgeny Grin ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Gerry Reno @ 2016-11-02 15:47 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-02 15:47 Windows 10 updates causes fork retry no child processes Gerry Reno @ 2016-11-02 17:31 ` Evgeny Grin 2016-11-03 0:05 ` Gerry Reno 2016-11-03 5:06 ` Brian Inglis 2016-11-03 9:13 ` Marko Božiković 2 siblings, 1 reply; 23+ messages in thread From: Evgeny Grin @ 2016-11-02 17:31 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-02 17:31 ` Evgeny Grin @ 2016-11-03 0:05 ` Gerry Reno 0 siblings, 0 replies; 23+ messages in thread From: Gerry Reno @ 2016-11-03 0:05 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-02 15:47 Windows 10 updates causes fork retry no child processes Gerry Reno 2016-11-02 17:31 ` Evgeny Grin @ 2016-11-03 5:06 ` Brian Inglis 2016-11-03 6:06 ` Gerry Reno 2016-11-03 9:13 ` Marko Božiković 2 siblings, 1 reply; 23+ messages in thread From: Brian Inglis @ 2016-11-03 5:06 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-03 5:06 ` Brian Inglis @ 2016-11-03 6:06 ` Gerry Reno 2016-11-03 7:02 ` Marco Atzeri ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Gerry Reno @ 2016-11-03 6:06 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-03 6:06 ` Gerry Reno @ 2016-11-03 7:02 ` Marco Atzeri 2016-11-03 13:01 ` Brian Inglis 2016-11-03 14:31 ` Hans-Bernhard Bröker 2 siblings, 0 replies; 23+ messages in thread From: Marco Atzeri @ 2016-11-03 7:02 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-03 6:06 ` Gerry Reno 2016-11-03 7:02 ` Marco Atzeri @ 2016-11-03 13:01 ` Brian Inglis 2016-11-03 13:42 ` Gerry Reno 2016-11-03 14:31 ` Hans-Bernhard Bröker 2 siblings, 1 reply; 23+ messages in thread From: Brian Inglis @ 2016-11-03 13:01 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-03 13:01 ` Brian Inglis @ 2016-11-03 13:42 ` Gerry Reno 2016-11-03 13:46 ` Eliot Moss 0 siblings, 1 reply; 23+ messages in thread From: Gerry Reno @ 2016-11-03 13:42 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-03 13:42 ` Gerry Reno @ 2016-11-03 13:46 ` Eliot Moss 2016-11-03 17:08 ` Brian Inglis 0 siblings, 1 reply; 23+ messages in thread From: Eliot Moss @ 2016-11-03 13:46 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-03 13:46 ` Eliot Moss @ 2016-11-03 17:08 ` Brian Inglis 0 siblings, 0 replies; 23+ messages in thread From: Brian Inglis @ 2016-11-03 17:08 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-03 6:06 ` Gerry Reno 2016-11-03 7:02 ` Marco Atzeri 2016-11-03 13:01 ` Brian Inglis @ 2016-11-03 14:31 ` Hans-Bernhard Bröker 2016-11-03 14:58 ` Gerry Reno 2016-11-07 16:17 ` L. A. Walsh 2 siblings, 2 replies; 23+ messages in thread From: Hans-Bernhard Bröker @ 2016-11-03 14:31 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-03 14:31 ` Hans-Bernhard Bröker @ 2016-11-03 14:58 ` Gerry Reno 2016-11-03 17:28 ` Brian Inglis 2016-11-07 16:17 ` L. A. Walsh 1 sibling, 1 reply; 23+ messages in thread From: Gerry Reno @ 2016-11-03 14:58 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-03 14:58 ` Gerry Reno @ 2016-11-03 17:28 ` Brian Inglis 2016-11-03 18:33 ` Gerry Reno 0 siblings, 1 reply; 23+ messages in thread From: Brian Inglis @ 2016-11-03 17:28 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-03 17:28 ` Brian Inglis @ 2016-11-03 18:33 ` Gerry Reno 2016-11-03 18:47 ` Achim Gratz 2016-11-03 22:08 ` Brian Inglis 0 siblings, 2 replies; 23+ messages in thread From: Gerry Reno @ 2016-11-03 18:33 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-03 18:33 ` Gerry Reno @ 2016-11-03 18:47 ` Achim Gratz 2016-11-03 19:02 ` Gerry Reno 2016-11-03 22:08 ` Brian Inglis 1 sibling, 1 reply; 23+ messages in thread From: Achim Gratz @ 2016-11-03 18:47 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-03 18:47 ` Achim Gratz @ 2016-11-03 19:02 ` Gerry Reno 2016-11-03 19:11 ` Achim Gratz 0 siblings, 1 reply; 23+ messages in thread From: Gerry Reno @ 2016-11-03 19:02 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-03 19:02 ` Gerry Reno @ 2016-11-03 19:11 ` Achim Gratz 0 siblings, 0 replies; 23+ messages in thread From: Achim Gratz @ 2016-11-03 19:11 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-03 18:33 ` Gerry Reno 2016-11-03 18:47 ` Achim Gratz @ 2016-11-03 22:08 ` Brian Inglis 2016-11-03 22:28 ` Gerry Reno 2016-11-04 18:40 ` Achim Gratz 1 sibling, 2 replies; 23+ messages in thread From: Brian Inglis @ 2016-11-03 22:08 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-03 22:08 ` Brian Inglis @ 2016-11-03 22:28 ` Gerry Reno 2016-11-04 18:40 ` Achim Gratz 1 sibling, 0 replies; 23+ messages in thread From: Gerry Reno @ 2016-11-03 22:28 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-03 22:08 ` Brian Inglis 2016-11-03 22:28 ` Gerry Reno @ 2016-11-04 18:40 ` Achim Gratz 2016-11-05 0:25 ` Gerry Reno 1 sibling, 1 reply; 23+ messages in thread From: Achim Gratz @ 2016-11-04 18:40 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-04 18:40 ` Achim Gratz @ 2016-11-05 0:25 ` Gerry Reno 0 siblings, 0 replies; 23+ messages in thread From: Gerry Reno @ 2016-11-05 0:25 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-03 14:31 ` Hans-Bernhard Bröker 2016-11-03 14:58 ` Gerry Reno @ 2016-11-07 16:17 ` L. A. Walsh 1 sibling, 0 replies; 23+ messages in thread From: L. A. Walsh @ 2016-11-07 16:17 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Windows 10 updates causes fork retry no child processes 2016-11-02 15:47 Windows 10 updates causes fork retry no child processes Gerry Reno 2016-11-02 17:31 ` Evgeny Grin 2016-11-03 5:06 ` Brian Inglis @ 2016-11-03 9:13 ` Marko Božiković 2 siblings, 0 replies; 23+ messages in thread From: Marko Božiković @ 2016-11-03 9:13 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2016-11-07 16:17 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-11-02 15:47 Windows 10 updates causes fork retry no child processes Gerry Reno 2016-11-02 17:31 ` Evgeny Grin 2016-11-03 0:05 ` Gerry Reno 2016-11-03 5:06 ` Brian Inglis 2016-11-03 6:06 ` Gerry Reno 2016-11-03 7:02 ` Marco Atzeri 2016-11-03 13:01 ` Brian Inglis 2016-11-03 13:42 ` Gerry Reno 2016-11-03 13:46 ` Eliot Moss 2016-11-03 17:08 ` Brian Inglis 2016-11-03 14:31 ` Hans-Bernhard Bröker 2016-11-03 14:58 ` Gerry Reno 2016-11-03 17:28 ` Brian Inglis 2016-11-03 18:33 ` Gerry Reno 2016-11-03 18:47 ` Achim Gratz 2016-11-03 19:02 ` Gerry Reno 2016-11-03 19:11 ` Achim Gratz 2016-11-03 22:08 ` Brian Inglis 2016-11-03 22:28 ` Gerry Reno 2016-11-04 18:40 ` Achim Gratz 2016-11-05 0:25 ` Gerry Reno 2016-11-07 16:17 ` L. A. Walsh 2016-11-03 9:13 ` Marko Božiković
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).