[This followup was posted to alt.windows7.general and a copy was sent to
the cited author.]

Exactly 6 hours after a boot, I receive an error 40 ("The following fatal
alert was received: 40.", Schannel Exit code 40), Event ID:36887, and the
exact same error repeats itself every 6 hours, exactly.

My first suspect was Avast (free), so I disabled it; just to make sure, I
uninstalled it completely (using avastclear.exe). It made no difference.
My only other AV is MalwareBytes (free), but the free version updates its
virus definitions only when I launch a scan manually, never
automatically.

The only way I am able to stop the error from popping up every 6 hours is
by switching my default browser (from Firefox) to Chrome and disabling
TLS 1.2.

It appears to be a protocol incompatibility, but the server then tries
another protocol, which seems to work. Since I can't find anything
untoward occurring as a result of the error, I suppose I can live with
it. Still, I would feel a lot more comfortable if I knew where it came
from.

Can anyone tell me how to detect the
program|application|utility|service|gremlin that is causing the error?
After all, I know exactly when it occurred and, more relevant perhaps,
exactly when it will occur again. Are there any logs, dumps, traps,
utilities, tools that will supply an actual name?

--

Norman B. Grover
Jerusalem, Israel

Norman B. Grover wrote:
> [This followup was posted to alt.windows7.general and a copy was sent to
> the cited author.]
>
> Exactly 6 hours after a boot, I receive an error 40 ("The following fatal
> alert was received: 40.", Schannel Exit code 40), Event ID:36887, and the
> exact same error repeats itself every 6 hours, exactly.
>
> My first suspect was Avast (free), so I disabled it; just to make sure, I
> uninstalled it completely (using avastclear.exe). It made no difference.
> My only other AV is MalwareBytes (free), but the free version updates its
> virus definitions only when I launch a scan manually, never
> automatically.
>
> The only way I am able to stop the error from popping up every 6 hours is
> by switching my default browser (from Firefox) to Chrome and disabling
> TLS 1.2.
>
> It appears to be a protocol incompatibility, but the server then tries
> another protocol, which seems to work. Since I can't find anything
> untoward occurring as a result of the error, I suppose I can live with
> it. Still, I would feel a lot more comfortable if I knew where it came
> from.
>
> Can anyone tell me how to detect the
> program|application|utility|service|gremlin that is causing the error?
> After all, I know exactly when it occurred and, more relevant perhaps,
> exactly when it will occur again. Are there any logs, dumps, traps,
> utilities, tools that will supply an actual name?

Googling "eventid 36887" uncovers a ton of reports starting
in 2013 or 2014 or so.

https://community.spiceworks.com/topic/401868-schannel-fatal-alert-40-what-is-going-on

"Low and behold, there was a value under the key

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
called "fipsalgorithmpolicy", and it was set to 1.

After setting it back to 0 an rebooting, IE started
advertising the RC4 algorithm properly."

It's hard to tell if that's the right thing to do or not.

You get this every six hours -- some people get it every
two minutes or so.

As for the notion that the above policy is "for Internet Explorer",
the thing is, some browsers honor the IE settings and follow
them too. The purpose of this logic, is the Microsoft GUI
then controls the behavior of more than one browser at the
same time.

*******

To determine the feature set of the browser:

https://www.ssllabs.com/ssltest/viewMyClient.html

You can run that, before and after making changes. Perhaps
while running that in an affected browser, you'll even get
an instance of that EventID being recorded.

Paul

[This followup was posted to alt.windows7.general and a copy was sent to
the cited author.]

In article <MPG.3bb3c2a3dcd64891989686@news.eternal-september.org>,
norman@md.huji.ac.il says...
>
> [This followup was posted to alt.windows7.general and a copy was sent to
> the cited author.]
>
> Exactly 6 hours after a boot, I receive an error 40 ("The following fatal
> alert was received: 40.", Schannel Exit code 40), Event ID:36887, and the
> exact same error repeats itself every 6 hours, exactly.
>
> My first suspect was Avast (free), so I disabled it; just to make sure, I
> uninstalled it completely (using avastclear.exe). It made no difference.
> My only other AV is MalwareBytes (free), but the free version updates its
> virus definitions only when I launch a scan manually, never
> automatically.
>
> The only way I am able to stop the error from popping up every 6 hours is
> by switching my default browser (from Firefox) to Chrome and disabling
> TLS 1.2.
>
> It appears to be a protocol incompatibility, but the server then tries
> another protocol, which seems to work. Since I can't find anything
> untoward occurring as a result of the error, I suppose I can live with
> it. Still, I would feel a lot more comfortable if I knew where it came
> from.
>
> Can anyone tell me how to detect the
> program|application|utility|service|gremlin that is causing the error?
> After all, I know exactly when it occurred and, more relevant perhaps,
> exactly when it will occur again. Are there any logs, dumps, traps,
> utilities, tools that will supply an actual name?

Correction: I am now unable to stop the error by switching browser to
Chrome and disabling TLS 1.2; the only way I can stop the damn thing is
by going off-line! Sorry. (And the original post was not, of course, a
followup, but the start of a new thread. Sorry about that too.)

--

Norman B. Grover
Jerusalem, Israel

Does anything show in Event Viewer?

--
Brian Gregory (in England).

[This followup was posted to alt.windows7.general and a copy was sent to
the cited author.]

In article <sicc2l$1iod$1@gioia.aioe.org>, nospam@needed.invalid says...
>
> Norman B. Grover wrote:
> > [This followup was posted to alt.windows7.general and a copy was sent to
> > the cited author.]
> >
> > Exactly 6 hours after a boot, I receive an error 40 ("The following fatal
> > alert was received: 40.", Schannel Exit code 40), Event ID:36887, and the
> > exact same error repeats itself every 6 hours, exactly.
> >
> > My first suspect was Avast (free), so I disabled it; just to make sure, I
> > uninstalled it completely (using avastclear.exe). It made no difference.
> > My only other AV is MalwareBytes (free), but the free version updates its
> > virus definitions only when I launch a scan manually, never
> > automatically.
> >
> > The only way I am able to stop the error from popping up every 6 hours is
> > by switching my default browser (from Firefox) to Chrome and disabling
> > TLS 1.2.
> >
> > It appears to be a protocol incompatibility, but the server then tries
> > another protocol, which seems to work. Since I can't find anything
> > untoward occurring as a result of the error, I suppose I can live with
> > it. Still, I would feel a lot more comfortable if I knew where it came
> > from.
> >
> > Can anyone tell me how to detect the
> > program|application|utility|service|gremlin that is causing the error?
> > After all, I know exactly when it occurred and, more relevant perhaps,
> > exactly when it will occur again. Are there any logs, dumps, traps,
> > utilities, tools that will supply an actual name?
>
> Googling "eventid 36887" uncovers a ton of reports starting
> in 2013 or 2014 or so.
>
> https://community.spiceworks.com/topic/401868-schannel-fatal-alert-40-what-is-going-on
>
> "Low and behold, there was a value under the key
>
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
> called "fipsalgorithmpolicy", and it was set to 1.
>
> After setting it back to 0 an rebooting, IE started
> advertising the RC4 algorithm properly."
>
> It's hard to tell if that's the right thing to do or not.

My fipsalgorithmpolicy was already set to 0.

>
> You get this every six hours -- some people get it every
> two minutes or so.

Maybe I should quit while I'm ahead (by 5hr58min or so).
On the other hand, every time I test something, I have to wait 6hr for
the result.

>
> As for the notion that the above policy is "for Internet Explorer",
> the thing is, some browsers honor the IE settings and follow
> them too. The purpose of this logic, is the Microsoft GUI
> then controls the behavior of more than one browser at the
> same time.
>
> *******
>
> To determine the feature set of the browser:
>
> https://www.ssllabs.com/ssltest/viewMyClient.html
>
> You can run that, before and after making changes. Perhaps
> while running that in an affected browser, you'll even get
> an instance of that EventID being recorded.

I'll give it a try. Thank you.

>
> Paul

--

Norman B. Grover
Jerusalem, Israel

[This followup was posted to alt.windows7.general and a copy was sent to
the cited author.]

In article <iqts8tFkvdhU1@mid.individual.net>, void-invalid-dead-
dontuse@email.invalid says...
>
> Does anything show in Event Viewer?

The Windows Logs>System toggled between "Information: The WMI Performance
Adapter service entered the running state" and ..."entered the stopped
state" (Event ID 7036) 19 times in the minute that Error 40 popped up,
less frequently at other times; nothing else at all in Windows Logs>
System except for the 'Error 40' itself every 6 hours.

--

Norman B. Grover
Jerusalem, Israel

On Tue, 21 Sep 2021 at 11:22:03, Norman B. Grover <norman@md.huji.ac.il>
wrote (my responses usually follow points raised):
[]
>The only way I am able to stop the error from popping up every 6 hours is
>by switching my default browser (from Firefox) to Chrome and disabling
>TLS 1.2.
[]
Does it happen if Firefox is not actually running at the error moment?

If it does, is that still the case if Firefox has not been used at all
since the start of the 6 hours?

If it still does, how about if you've not done _anything_ that "goes
online" in the 6 hours? Probably difficult to test, as so much does
these days (prog.s calling home, if only to check for updates, and so
on). How about if you turn off your "router" (UK term)?

Is disabling TSL 1.2 something you do within Chrome, or in some other
way?

Not that I have any answers, just these seem questions whose answers
might help others to help you.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Never be led astray onto the path of virtue.

[This followup was posted to alt.windows7.general and a copy was sent to
the cited author.]

In article <D3dwGZoYzcShFwNi@255soft.uk>, G6JPG@255soft.uk says...
>
> On Tue, 21 Sep 2021 at 11:22:03, Norman B. Grover <norman@md.huji.ac.il>
> wrote (my responses usually follow points raised):
> []
> >The only way I am able to stop the error from popping up every 6 hours is
> >by switching my default browser (from Firefox) to Chrome and disabling
> >TLS 1.2.
> []
> Does it happen if Firefox is not actually running at the error moment?
>
> If it does, is that still the case if Firefox has not been used at all
> since the start of the 6 hours?
>
> If it still does, how about if you've not done _anything_ that "goes
> online" in the 6 hours? Probably difficult to test, as so much does
> these days (prog.s calling home, if only to check for updates, and so
> on). How about if you turn off your "router" (UK term)?
>
> Is disabling TSL 1.2 something you do within Chrome, or in some other
> way?
>

As I posted above, I was not able to reproduce being able to stop the
error from popping up by switching my browser to Chrome and disabling TLS
1.2; I'm sorry you missed the correction (and the apology).

On the other hand, your post raises several possible reasons why my
repeat run may have failed. Unfortunately, a trial run is 6 hours, and
the first (and only) time I got the damn thing to stop was over two days
ago, so I am kind of stuck, unless some kind (and very knowledgeable)
reader can suggest preferred possible configurations from among your
alternatives, to narrow down the potential runs (3 per day).

> Not that I have any answers, just these seem questions whose answers
> might help others to help you.

--

Norman B. Grover
Jerusalem, Israel

Norman B. Grover <norman@md.huji.ac.il> wrote:
> [This followup was posted to alt.windows7.general and a copy was sent to
> the cited author.]
>
> In article <D3dwGZoYzcShFwNi@255soft.uk>, G6JPG@255soft.uk says...
>>
>> On Tue, 21 Sep 2021 at 11:22:03, Norman B. Grover <norman@md.huji.ac.il>
>> wrote (my responses usually follow points raised):
>> []
>>> The only way I am able to stop the error from popping up every 6 hours is
>>> by switching my default browser (from Firefox) to Chrome and disabling
>>> TLS 1.2.
>> []
>> Does it happen if Firefox is not actually running at the error moment?
>>
>> If it does, is that still the case if Firefox has not been used at all
>> since the start of the 6 hours?
>>
>> If it still does, how about if you've not done _anything_ that "goes
>> online" in the 6 hours? Probably difficult to test, as so much does
>> these days (prog.s calling home, if only to check for updates, and so
>> on). How about if you turn off your "router" (UK term)?
>>
>> Is disabling TSL 1.2 something you do within Chrome, or in some other
>> way?
>>
>
> As I posted above, I was not able to reproduce being able to stop the
> error from popping up by switching my browser to Chrome and disabling TLS
> 1.2; I'm sorry you missed the correction (and the apology).
>
> On the other hand, your post raises several possible reasons why my
> repeat run may have failed. Unfortunately, a trial run is 6 hours, and
> the first (and only) time I got the damn thing to stop was over two days
> ago, so I am kind of stuck, unless some kind (and very knowledgeable)
> reader can suggest preferred possible configurations from among your
> alternatives, to narrow down the potential runs (3 per day).
>
>> Not that I have any answers, just these seem questions whose answers
>> might help others to help you.
>
>
>

Anything in Time Scheduler?

--
Zaidy036

On Tue, 21 Sep 2021 06:27:32 -0400, Paul wrote:
>
> To determine the feature set of the browser:
>
> https://www.ssllabs.com/ssltest/viewMyClient.html
>
> You can run that, before and after making changes. Perhaps
> while running that in an affected browser, you'll even get
> an instance of that EventID being recorded.

I also have different but still SChannel related problem.

With that browser test on my Firefox v91, I don't see any error (or red
text). Only warnings (yellow text): TLS 1.0 & 1.1 being enabled, and weak
chiper suites starting from TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) to
the rest of the items in the list. Protocol support is good (green text). No
vulnerability whatsoever.

That should be good, right?

On Tue, 21 Sep 2021 11:22:03 +0300, Norman B. Grover wrote:
> [This followup was posted to alt.windows7.general and a copy was sent to
> the cited author.]
>
> Exactly 6 hours after a boot, I receive an error 40 ("The following fatal
> alert was received: 40.", Schannel Exit code 40), Event ID:36887, and the
> exact same error repeats itself every 6 hours, exactly.
>
> My first suspect was Avast (free), so I disabled it; just to make sure, I
> uninstalled it completely (using avastclear.exe). It made no difference.
> My only other AV is MalwareBytes (free), but the free version updates its
> virus definitions only when I launch a scan manually, never
> automatically.
>
> The only way I am able to stop the error from popping up every 6 hours is
> by switching my default browser (from Firefox) to Chrome and disabling
> TLS 1.2.
>
> It appears to be a protocol incompatibility, but the server then tries
> another protocol, which seems to work. Since I can't find anything
> untoward occurring as a result of the error, I suppose I can live with
> it. Still, I would feel a lot more comfortable if I knew where it came
> from.
>
> Can anyone tell me how to detect the
> program|application|utility|service|gremlin that is causing the error?
> After all, I know exactly when it occurred and, more relevant perhaps,
> exactly when it will occur again. Are there any logs, dumps, traps,
> utilities, tools that will supply an actual name?

According to MSDN, SChannel error code 40 is labelled as
TLS1_ALERT_HANDSHAKE_FAILURE.

I have similar SChannel related error, but with error code 70 which is
labelled as TLS1_ALERT_PROTOCOL_VERSION.

I've already rummaged most past discussions about SChannel errors. The
actual cause varies from inteference by anti virus or security related
software, to disabled TLS versions; which were solved by either updating the
inteferring software, or enabling all TLS versions. But they're applicable
to only a handful of people. Most, including me, still suffer the problem.

Either way, these seem to be TLS1 related problem, or within the SChannel
itself as a whole.

JJ wrote:
> On Tue, 21 Sep 2021 06:27:32 -0400, Paul wrote:
>> To determine the feature set of the browser:
>>
>> https://www.ssllabs.com/ssltest/viewMyClient.html
>>
>> You can run that, before and after making changes. Perhaps
>> while running that in an affected browser, you'll even get
>> an instance of that EventID being recorded.
>
> I also have different but still SChannel related problem.
>
> With that browser test on my Firefox v91, I don't see any error (or red
> text). Only warnings (yellow text): TLS 1.0 & 1.1 being enabled, and weak
> chiper suites starting from TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) to
> the rest of the items in the list. Protocol support is good (green text). No
> vulnerability whatsoever.
>
> That should be good, right?

The weak ones might be RC4. It might have gone as low as
RC4-40 at one time, weak as piss (crackable).

Really, the SChannel should not be complaining!

If something is missing from SChannel, then a browser
can't use it. The browser and the server negotiate
the best common denominator they've got, to make a
secure connection. If a server insisted on a weak
crypto, that would be bad.

You can test a domain, and see what it supports.

https://www.ssllabs.com/ssltest/analyze.html?d=walmart.com

Like, if it supports RC4, then only a really old
browser that only has RC4 would select RC4 as the
choice. If the two ends have something better than
RC4, they should be using it. If the browser
doesn't have RC4 at all, then it's not going to be
able to contact an RC4-only server.

And the deal is, a message should appear in the
browser, announcing the negotiation failed. It's
not up to the SChannel to be throwing crap into
the Event Viewer. That suggests a functional failure
of the SChannel. In this case, it gives the appearance
of some issue related to missing protocol, but again,
it's not the job of SChannel to comment on that. Only if
the attempt at protocol setup fails, should the Event
Viewer get an item. If both ends offer XYZ protocol,
during negotiation phase, but XYZ fails on the SChannel
side (software fail at Microsoft level), then there should
be an Event Viewer item. But if XYZ no longer exists
in SChannel at all, it's been removed or disabled with
a registry setting, then only the browser should
report it could not establish a secure connection.

Use Internet Explorer and https, if you want to
see "fail whales" in action. Various versions of
IE make great test tools for failing at life. Some
of the older IE versions, cannot connect to any https.

Paul

On Tue, 21 Sep 2021 11:22:03 +0300, Norman B. Grover wrote:
> [This followup was posted to alt.windows7.general and a copy was sent to
> the cited author.]

It was an original article, not a followup, and there was no "cited
author". I think you may want to check your settings for what
boilerplate gets inserted in your posted articles.

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
https://OakRoadSystems.com/
Shikata ga nai...

Norman B. Grover wrote:
> [This followup was posted to alt.windows7.general and a copy was sent to
> the cited author.]
>
> In article <sicc2l$1iod$1@gioia.aioe.org>, nospam@needed.invalid says...
>>
>> Norman B. Grover wrote:
>>> [This followup was posted to alt.windows7.general and a copy was sent to
>>> the cited author.]
>>>
>>> Exactly 6 hours after a boot, I receive an error 40 ("The following fatal
>>> alert was received: 40.", Schannel Exit code 40), Event ID:36887, and the
>>> exact same error repeats itself every 6 hours, exactly.
>>>
>>> My first suspect was Avast (free), so I disabled it; just to make sure, I
>>> uninstalled it completely (using avastclear.exe). It made no difference.
>>> My only other AV is MalwareBytes (free), but the free version updates its
>>> virus definitions only when I launch a scan manually, never
>>> automatically.
>>>
>>> The only way I am able to stop the error from popping up every 6 hours is
>>> by switching my default browser (from Firefox) to Chrome and disabling
>>> TLS 1.2.
>>>
>>> It appears to be a protocol incompatibility, but the server then tries
>>> another protocol, which seems to work. Since I can't find anything
>>> untoward occurring as a result of the error, I suppose I can live with
>>> it. Still, I would feel a lot more comfortable if I knew where it came
>>> from.
>>>
>>> Can anyone tell me how to detect the
>>> program|application|utility|service|gremlin that is causing the error?
>>> After all, I know exactly when it occurred and, more relevant perhaps,
>>> exactly when it will occur again. Are there any logs, dumps, traps,
>>> utilities, tools that will supply an actual name?
>>
>> Googling "eventid 36887" uncovers a ton of reports starting
>> in 2013 or 2014 or so.
>>
>> https://community.spiceworks.com/topic/401868-schannel-fatal-alert-40-what-is-going-on
>>
>> "Low and behold, there was a value under the key
>>
>> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
>> called "fipsalgorithmpolicy", and it was set to 1.
>>
>> After setting it back to 0 an rebooting, IE started
>> advertising the RC4 algorithm properly."
>>
>> It's hard to tell if that's the right thing to do or not.
>
> My fipsalgorithmpolicy was already set to 0.
>
>>
>> You get this every six hours -- some people get it every
>> two minutes or so.
>
> Maybe I should quit while I'm ahead (by 5hr58min or so).
> On the other hand, every time I test something, I have to wait 6hr for
> the result.

I wonder if it reads the computer clock or uses a count?

[This followup was posted to alt.windows7.general and a copy was sent to
the cited author.]

In article <sicud6$fah$1@dont-email.me>, Zaidy036@air.isp.spam says...
>
> Norman B. Grover <norman@md.huji.ac.il> wrote:
> > [This followup was posted to alt.windows7.general and a copy was sent to
> > the cited author.]
> >
> > In article <D3dwGZoYzcShFwNi@255soft.uk>, G6JPG@255soft.uk says...
> >>
> >> On Tue, 21 Sep 2021 at 11:22:03, Norman B. Grover <norman@md.huji.ac.il>
> >> wrote (my responses usually follow points raised):
> >> []
> >>> The only way I am able to stop the error from popping up every 6 hours is
> >>> by switching my default browser (from Firefox) to Chrome and disabling
> >>> TLS 1.2.
> >> []
> >> Does it happen if Firefox is not actually running at the error moment?
> >>
> >> If it does, is that still the case if Firefox has not been used at all
> >> since the start of the 6 hours?
> >>
> >> If it still does, how about if you've not done _anything_ that "goes
> >> online" in the 6 hours? Probably difficult to test, as so much does
> >> these days (prog.s calling home, if only to check for updates, and so
> >> on). How about if you turn off your "router" (UK term)?
> >>
> >> Is disabling TSL 1.2 something you do within Chrome, or in some other
> >> way?
> >>
> >
> > As I posted above, I was not able to reproduce being able to stop the
> > error from popping up by switching my browser to Chrome and disabling TLS
> > 1.2; I'm sorry you missed the correction (and the apology).
> >
> > On the other hand, your post raises several possible reasons why my
> > repeat run may have failed. Unfortunately, a trial run is 6 hours, and
> > the first (and only) time I got the damn thing to stop was over two days
> > ago, so I am kind of stuck, unless some kind (and very knowledgeable)
> > reader can suggest preferred possible configurations from among your
> > alternatives, to narrow down the potential runs (3 per day).
> >
> >> Not that I have any answers, just these seem questions whose answers
> >> might help others to help you.
> >
> >
> >
>
> Anything in Time Scheduler?

A great deal, most of which made fascinating if unintelligible reading,
nothing with a repeat period even remotely approaching 6hr.

--

Norman B. Grover
Jerusalem, Israel

[This followup was posted to alt.windows7.general and a copy was sent to
the cited author.]

In article <sidn27$31p$1@dont-email.me>, Paul@Houston.Texas says...
>
> Norman B. Grover wrote:
> > [This followup was posted to alt.windows7.general and a copy was sent to
> > the cited author.]
> >
> > In article <sicc2l$1iod$1@gioia.aioe.org>, nospam@needed.invalid says...
> >>
> >> Norman B. Grover wrote:
> >>> [This followup was posted to alt.windows7.general and a copy was sent to
> >>> the cited author.]
> >>>
> >>> Exactly 6 hours after a boot, I receive an error 40 ("The following fatal
> >>> alert was received: 40.", Schannel Exit code 40), Event ID:36887, and the
> >>> exact same error repeats itself every 6 hours, exactly.
> >>>
> >>> My first suspect was Avast (free), so I disabled it; just to make sure, I
> >>> uninstalled it completely (using avastclear.exe). It made no difference.
> >>> My only other AV is MalwareBytes (free), but the free version updates its
> >>> virus definitions only when I launch a scan manually, never
> >>> automatically.
> >>>
> >>> The only way I am able to stop the error from popping up every 6 hours is
> >>> by switching my default browser (from Firefox) to Chrome and disabling
> >>> TLS 1.2.
> >>>
> >>> It appears to be a protocol incompatibility, but the server then tries
> >>> another protocol, which seems to work. Since I can't find anything
> >>> untoward occurring as a result of the error, I suppose I can live with
> >>> it. Still, I would feel a lot more comfortable if I knew where it came
> >>> from.
> >>>
> >>> Can anyone tell me how to detect the
> >>> program|application|utility|service|gremlin that is causing the error?
> >>> After all, I know exactly when it occurred and, more relevant perhaps,
> >>> exactly when it will occur again. Are there any logs, dumps, traps,
> >>> utilities, tools that will supply an actual name?
> >>
> >> Googling "eventid 36887" uncovers a ton of reports starting
> >> in 2013 or 2014 or so.
> >>
> >> https://community.spiceworks.com/topic/401868-schannel-fatal-alert-40-what-is-going-on
> >>
> >> "Low and behold, there was a value under the key
> >>
> >> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
> >> called "fipsalgorithmpolicy", and it was set to 1.
> >>
> >> After setting it back to 0 an rebooting, IE started
> >> advertising the RC4 algorithm properly."
> >>
> >> It's hard to tell if that's the right thing to do or not.
> >
> > My fipsalgorithmpolicy was already set to 0.
> >
> >>
> >> You get this every six hours -- some people get it every
> >> two minutes or so.
> >
> > Maybe I should quit while I'm ahead (by 5hr58min or so).
> > On the other hand, every time I test something, I have to wait 6hr for
> > the result.
>
> I wonder if it reads the computer clock or uses a count?

I may be able to test that (tomorrow, it's nighttime here now) by
fiddling with the clock. Would a definite answer (that is, count or
clock) help?

--

Norman B. Grover
Jerusalem, Israel

[This followup was posted to alt.windows7.general and a copy was sent to
the cited author.]

In article <13ljv9x7khjlw.1uhl5228n5o93$.dlg@40tude.net>,
jj4public@gmail.com says...
>
> On Tue, 21 Sep 2021 11:22:03 +0300, Norman B. Grover wrote:
> > [This followup was posted to alt.windows7.general and a copy was sent to
> > the cited author.]
> >
> > Exactly 6 hours after a boot, I receive an error 40 ("The following fatal
> > alert was received: 40.", Schannel Exit code 40), Event ID:36887, and the
> > exact same error repeats itself every 6 hours, exactly.
> >
> > My first suspect was Avast (free), so I disabled it; just to make sure, I
> > uninstalled it completely (using avastclear.exe). It made no difference.
> > My only other AV is MalwareBytes (free), but the free version updates its
> > virus definitions only when I launch a scan manually, never
> > automatically.
> >
> > The only way I am able to stop the error from popping up every 6 hours is
> > by switching my default browser (from Firefox) to Chrome and disabling
> > TLS 1.2.
> >
> > It appears to be a protocol incompatibility, but the server then tries
> > another protocol, which seems to work. Since I can't find anything
> > untoward occurring as a result of the error, I suppose I can live with
> > it. Still, I would feel a lot more comfortable if I knew where it came
> > from.
> >
> > Can anyone tell me how to detect the
> > program|application|utility|service|gremlin that is causing the error?
> > After all, I know exactly when it occurred and, more relevant perhaps,
> > exactly when it will occur again. Are there any logs, dumps, traps,
> > utilities, tools that will supply an actual name?
>
> According to MSDN, SChannel error code 40 is labelled as
> TLS1_ALERT_HANDSHAKE_FAILURE.
>
> I have similar SChannel related error, but with error code 70 which is
> labelled as TLS1_ALERT_PROTOCOL_VERSION.
>
> I've already rummaged most past discussions about SChannel errors. The
> actual cause varies from inteference by anti virus or security related
> software, to disabled TLS versions; which were solved by either updating the
> inteferring software, or enabling all TLS versions. But they're applicable
> to only a handful of people. Most, including me, still suffer the problem.
>
> Either way, these seem to be TLS1 related problem, or within the SChannel
> itself as a whole.

I too rummaged a lot, though probably not as much as you, and decided to
focus on my AV (mostly) and somewhat less on TLS and browsers. I did all
I could think of in each of those categories (with the emphasis on the
AV, like a complete uninstall of Avast), but no combination worked. I am
fast approaching the stage where I decide to live with my error 40.

If there were a problem 'within the SChannel itself as a whole', as you
say, how would I go about finding/fixing it?

--

Norman B. Grover
Jerusalem, Israel

Norman B. Grover wrote:
>
> In article <sidn27$31p$1@dont-email.me>, Paul@Houston.Texas says...
>> Norman B. Grover wrote:

>>> Maybe I should quit while I'm ahead (by 5hr58min or so).
>>> On the other hand, every time I test something, I have to wait 6hr for
>>> the result.
>> I wonder if it reads the computer clock or uses a count?
>
> I may be able to test that (tomorrow, it's nighttime here now) by
> fiddling with the clock. Would a definite answer (that is, count or
> clock) help?

If the time the message is logged is precise, this is being
scheduled somehow.

It could be, that a client program is scheduled to start
at a particular time. It could even be an HTML engine,
rather than a browser, that is being used by the OS,
and is spitting out that message.

If the event is predictably timed, you can run
Process Monitor and capture a trace before and after
the time point. Then scroll through it, looking for
the culprit. Process Monitor will record up to 199 million
events, records to RAM by default, but can be configured
to store the trace to disk.

https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

If a svchost was doing it, the svchost PID (process ID) number
is only consistent until the next reboot. On Pro, you could do

tasklist /svc

for details. Process Explorer (especially if run as Administrator),
can also provide process info.

Procmon is a decent, intermediate level tool for tracing.
It's what you use, when there aren't any other really
good choices. It can also be used to trace shutdown and
startup (most of it, not precisely all of it).

The root cause is more likely to be some third party code,
contacting a poorly maintained server.

Paul

Norman B. Grover wrote:
> [This followup was posted to alt.windows7.general and a copy was sent to
> the cited author.]
>
> In article <sidn27$31p$1@dont-email.me>, Paul@Houston.Texas says...
>>
>> Norman B. Grover wrote:
>>> [This followup was posted to alt.windows7.general and a copy was sent to
>>> the cited author.]
>>>
>>> In article <sicc2l$1iod$1@gioia.aioe.org>, nospam@needed.invalid says...
>>>>
>>>> Norman B. Grover wrote:
>>>>> [This followup was posted to alt.windows7.general and a copy was sent to
>>>>> the cited author.]
>>>>>
>>>>> Exactly 6 hours after a boot, I receive an error 40 ("The following fatal
>>>>> alert was received: 40.", Schannel Exit code 40), Event ID:36887, and the
>>>>> exact same error repeats itself every 6 hours, exactly.
>>>>>
>>>>> My first suspect was Avast (free), so I disabled it; just to make sure, I
>>>>> uninstalled it completely (using avastclear.exe). It made no difference.
>>>>> My only other AV is MalwareBytes (free), but the free version updates its
>>>>> virus definitions only when I launch a scan manually, never
>>>>> automatically.
>>>>>
>>>>> The only way I am able to stop the error from popping up every 6 hours is
>>>>> by switching my default browser (from Firefox) to Chrome and disabling
>>>>> TLS 1.2.
>>>>>
>>>>> It appears to be a protocol incompatibility, but the server then tries
>>>>> another protocol, which seems to work. Since I can't find anything
>>>>> untoward occurring as a result of the error, I suppose I can live with
>>>>> it. Still, I would feel a lot more comfortable if I knew where it came
>>>>> from.
>>>>>
>>>>> Can anyone tell me how to detect the
>>>>> program|application|utility|service|gremlin that is causing the error?
>>>>> After all, I know exactly when it occurred and, more relevant perhaps,
>>>>> exactly when it will occur again. Are there any logs, dumps, traps,
>>>>> utilities, tools that will supply an actual name?
>>>>
>>>> Googling "eventid 36887" uncovers a ton of reports starting
>>>> in 2013 or 2014 or so.
>>>>
>>>> https://community.spiceworks.com/topic/401868-schannel-fatal-alert-40-what-is-going-on
>>>>
>>>> "Low and behold, there was a value under the key
>>>>
>>>> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
>>>> called "fipsalgorithmpolicy", and it was set to 1.
>>>>
>>>> After setting it back to 0 an rebooting, IE started
>>>> advertising the RC4 algorithm properly."
>>>>
>>>> It's hard to tell if that's the right thing to do or not.
>>>
>>> My fipsalgorithmpolicy was already set to 0.
>>>
>>>>
>>>> You get this every six hours -- some people get it every
>>>> two minutes or so.
>>>
>>> Maybe I should quit while I'm ahead (by 5hr58min or so).
>>> On the other hand, every time I test something, I have to wait 6hr for
>>> the result.
>>
>> I wonder if it reads the computer clock or uses a count?
>
> I may be able to test that (tomorrow, it's nighttime here now) by
> fiddling with the clock. Would a definite answer (that is, count or
> clock) help?

It may not help directly but if it's the clock then you would not have
to wait 6 hours for the next event.

In article <sigfsf$tan$1@dont-email.me>, Paul@Houston.Texas says...
>
> Norman B. Grover wrote:
> > [This followup was posted to alt.windows7.general and a copy was sent to
> > the cited author.]
> >
> > In article <sidn27$31p$1@dont-email.me>, Paul@Houston.Texas says...
> >>
> >> Norman B. Grover wrote:
> >>> [This followup was posted to alt.windows7.general and a copy was sent to
> >>> the cited author.]
> >>>
> >>> In article <sicc2l$1iod$1@gioia.aioe.org>, nospam@needed.invalid says...
> >>>>
> >>>> Norman B. Grover wrote:
> >>>>> [This followup was posted to alt.windows7.general and a copy was sent to
> >>>>> the cited author.]
> >>>>>
> >>>>> Exactly 6 hours after a boot, I receive an error 40 ("The following fatal
> >>>>> alert was received: 40.", Schannel Exit code 40), Event ID:36887, and the
> >>>>> exact same error repeats itself every 6 hours, exactly.
> >>>>>
> >>>>> My first suspect was Avast (free), so I disabled it; just to make sure, I
> >>>>> uninstalled it completely (using avastclear.exe). It made no difference.
> >>>>> My only other AV is MalwareBytes (free), but the free version updates its
> >>>>> virus definitions only when I launch a scan manually, never
> >>>>> automatically.
> >>>>>
> >>>>> The only way I am able to stop the error from popping up every 6 hours is
> >>>>> by switching my default browser (from Firefox) to Chrome and disabling
> >>>>> TLS 1.2.
> >>>>>
> >>>>> It appears to be a protocol incompatibility, but the server then tries
> >>>>> another protocol, which seems to work. Since I can't find anything
> >>>>> untoward occurring as a result of the error, I suppose I can live with
> >>>>> it. Still, I would feel a lot more comfortable if I knew where it came
> >>>>> from.
> >>>>>
> >>>>> Can anyone tell me how to detect the
> >>>>> program|application|utility|service|gremlin that is causing the error?
> >>>>> After all, I know exactly when it occurred and, more relevant perhaps,
> >>>>> exactly when it will occur again. Are there any logs, dumps, traps,
> >>>>> utilities, tools that will supply an actual name?
> >>>>
> >>>> Googling "eventid 36887" uncovers a ton of reports starting
> >>>> in 2013 or 2014 or so.
> >>>>
> >>>> https://community.spiceworks.com/topic/401868-schannel-fatal-alert-40-what-is-going-on
> >>>>
> >>>> "Low and behold, there was a value under the key
> >>>>
> >>>> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
> >>>> called "fipsalgorithmpolicy", and it was set to 1.
> >>>>
> >>>> After setting it back to 0 an rebooting, IE started
> >>>> advertising the RC4 algorithm properly."
> >>>>
> >>>> It's hard to tell if that's the right thing to do or not.
> >>>
> >>> My fipsalgorithmpolicy was already set to 0.
> >>>
> >>>>
> >>>> You get this every six hours -- some people get it every
> >>>> two minutes or so.
> >>>
> >>> Maybe I should quit while I'm ahead (by 5hr58min or so).
> >>> On the other hand, every time I test something, I have to wait 6hr for
> >>> the result.
> >>
> >> I wonder if it reads the computer clock or uses a count?
> >
> > I may be able to test that (tomorrow, it's nighttime here now) by
> > fiddling with the clock. Would a definite answer (that is, count or
> > clock) help?
>
> It may not help directly but if it's the clock then you would not have
> to wait 6 hours for the next event.

The last error-40 was generated at 7:08am this morning. I advanced the
system clock manually by 10min, from 12:40pm to 12:50pm. The next error-
40 popped up at 1:18pm 'fudged' time; that is, exactly 6hr after its
predecessor. So whatever 'it' is, it uses a count rather than the
computer clock, as you appear to have suspected.

--

Norman B. Grover
Jerusalem, Israel

In article <MPG.3bb3ff5bc58ffd2798fe17@news.individual.net>,
the_stan_brown@fastmail.fm says...
>
> On Tue, 21 Sep 2021 11:22:03 +0300, Norman B. Grover wrote:
> > [This followup was posted to alt.windows7.general and a copy was sent to
> > the cited author.]
>
> It was an original article, not a followup, and there was no "cited
> author". I think you may want to check your settings for what
> boilerplate gets inserted in your posted articles.

You are quite right. I noticed that rather early on, and posted an
apology, but only now was I able to figure out how to fix it; I hope I
did. Sorry again. At my age, I should know better.

--

Norman B. Grover
Jerusalem, Israel

On Wed, 22 Sep 2021 22:36:25 +0300, Norman B. Grover wrote:
>
> If there were a problem 'within the SChannel itself as a whole', as you
> say, how would I go about finding/fixing it?

Since I'm pretty sure the system didn't used to be like that, it would mean
that the error is introduced by a Windows update. But I don't know which
Hotfix packages include the SCHANNEL.DLL file. If I know, I could try
uninstalling those Hotfixes one by one to find out which one exactly is
causing the error.

But for now, I simply disabled the logging so that the error isn't flooding
the System log.

On Thu, 23 Sep 2021 15:19:40 +0300, Norman B. Grover wrote:
>
> In article <MPG.3bb3ff5bc58ffd2798fe17@news.individual.net>,
> the_stan_brown@fastmail.fm says...
> >
> > On Tue, 21 Sep 2021 11:22:03 +0300, Norman B. Grover wrote:
> > > [This followup was posted to alt.windows7.general and a copy was sent to
> > > the cited author.]
> >
> > It was an original article, not a followup, and there was no "cited
> > author". I think you may want to check your settings for what
> > boilerplate gets inserted in your posted articles.
>
> You are quite right. I noticed that rather early on, and posted an
> apology, but only now was I able to figure out how to fix it; I hope I
> did. Sorry again. At my age, I should know better.

No problem -- thanks for finding and fixing it!

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
https://OakRoadSystems.com/
Shikata ga nai...

In article <sige4r$kvi$1@dont-email.me>, nospam@needed.invalid says...
>
> Norman B. Grover wrote:
> >
> > In article <sidn27$31p$1@dont-email.me>, Paul@Houston.Texas says...
> >> Norman B. Grover wrote:
>
> >>> Maybe I should quit while I'm ahead (by 5hr58min or so).
> >>> On the other hand, every time I test something, I have to wait 6hr for
> >>> the result.
> >> I wonder if it reads the computer clock or uses a count?
> >
> > I may be able to test that (tomorrow, it's nighttime here now) by
> > fiddling with the clock. Would a definite answer (that is, count or
> > clock) help?
>
> If the time the message is logged is precise, this is being
> scheduled somehow.
>
> It could be, that a client program is scheduled to start
> at a particular time. It could even be an HTML engine,
> rather than a browser, that is being used by the OS,
> and is spitting out that message.
>
> If the event is predictably timed, you can run
> Process Monitor and capture a trace before and after
> the time point. Then scroll through it, looking for
> the culprit. Process Monitor will record up to 199 million
> events, records to RAM by default, but can be configured
> to store the trace to disk.
>
> https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
>
> If a svchost was doing it, the svchost PID (process ID) number
> is only consistent until the next reboot. On Pro, you could do
>
> tasklist /svc
>
> for details. Process Explorer (especially if run as Administrator),
> can also provide process info.
>
> Procmon is a decent, intermediate level tool for tracing.
> It's what you use, when there aren't any other really
> good choices. It can also be used to trace shutdown and
> startup (most of it, not precisely all of it).
>
> The root cause is more likely to be some third party code,
> contacting a poorly maintained server.
>
> Paul

Thank you for the wealth of information. The Procmon version of your link
does not run under Windows 7 but I have a version that does. I set it up
to run during the 4min that span the error event (2min before, 2min
after), and got hundreds of thousands of entries. What do I do now? I
haven't a clue. Are there any filters you could suggest to exclude or
(preferably) include to narrow down the field somewhat? What am I looking
for? Perhaps, when the list is down to a few hundred entries, I could
compare it to a list with the same filters but running during a different
time (the previous hour?). I really don't know where to start, and any
advice would be welcome.

--

Norman B. Grover
Jerusalem, Israel

Norman B. Grover wrote:

>
> Thank you for the wealth of information. The Procmon version of your link
> does not run under Windows 7 but I have a version that does. I set it up
> to run during the 4min that span the error event (2min before, 2min
> after), and got hundreds of thousands of entries. What do I do now? I
> haven't a clue. Are there any filters you could suggest to exclude or
> (preferably) include to narrow down the field somewhat? What am I looking
> for? Perhaps, when the list is down to a few hundred entries, I could
> compare it to a list with the same filters but running during a different
> time (the previous hour?). I really don't know where to start, and any
> advice would be welcome.

I had a lot of trouble, making progress on this one.

First problem was, changing the logging level, I'm still not
seeing anything that I can find in Event Viewer, for SChannel.

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
EventLogging DWORD 1 <=== default value
128 <=== dump everything it has got to offer

So that part of the puzzle didn't work. My event viewer might have
36000 things in it, but the System one hardly grows. Less fluff
than on Windows XP.

*******

Next problem, was trying to craft a test case that would
cause the SChannel to "fail".

I tried to use "curl.exe" for this. There is a curl.exe on
Windows 10, but the api-*.dll references it makes on another
Windows, makes it impossible to use. I wasted *hours* trying
various api-* things in my disk drive collection, to no effect.
The loadlibrary one it seemed to be using, Windows 10 was somehow
serving that one up, without the file being visible on disk
for me to steal :-)

The api-ms-* DLLs are a kind of redirector. They are not real
DLLs. They provide a linkage between "new" things compiled with
Visual Studio, and the various OSes. But it looks to me, they're
there also, to prevent an executable on one OS, from being reused
on another. You might notice a browser installation now, has
its own collection of api-ms- files in the executable directory,
to "help" the loader.

*******

I finally found an old friend. This is mostly statically
compiled, so less opportunity for errant DLLs to interfere.

https://curl.se/windows/

https://curl.se/windows/dl-7.79.1/curl-7.79.1-win32-mingw.zip

https://curl.se/windows/dl-7.79.1/curl-7.79.1-win64-mingw.zip

This is an example of an invocation:

cd /d C:\curl-7.789.1-win64-mingw\bin # executing the curl.exe in "bin"

curl -v https://www.walmart.com --tlsv1.2 # force negotiation of a TLS 1.2

It dumps a log of all the steps in certificate ingestion and
so on, into the Command Prompt I was running it from.

In Procmon, I can see a reference to curl.exe accessing this area:

HKLM\System\CurrentControlSet\Services\WinSock2\Parameters\Protocol_Catalog9

So if something networking related was going on, you could
look for a Catalog9 in your trace perhaps. That's about the
only hook that looks even close to being a needle in the haystack.

That's still not an SChannel error. I still do not
have a way of generating an Schannel error on demand.
If I had an SChannel error in my trace, I might be
able to help you further with correlation. The Catalog9
isn't going to narrow things down enough, in a long trace.

*******

You can find various references to testing, but the nodes they
use may not be online at the moment.

https://techcommunity.microsoft.com/t5/azure-paas-blog/ssl-tls-connection-issue-troubleshooting-test-tools/ba-p/2240059

This one, for example, fails because the server is not running.
You can see, with this syntax, if a particular cipher was "broken",
you could force the SChannel to try to use it. That would be
the benefit of this sort of testing.

curl -v https://pingrds.redis.cache.windows.net:6380 --ciphers ECDHE-RSA-NULL-SHA --tlsv1.2

The other bit of info, is here. Apparently these kinds of
errors can be related to the user having "installed a certificate",
then living to regret it. The reason the helpers don't help much
near the end, is most of the posters at that point are
thread-crapping, hoping someone will care...

https://social.technet.microsoft.com/Forums/windowsserver/en-US/4c5430f5-43f6-41b4-97d3-03cfb3efa70b/schannel-error-event-id-36888-is-there-a-way-to-identify-what-causes-schannel-to-log-error?forum=winserverDS

Paul