In article <sip1vo$f0h$1@gioia.aioe.org>, nospam@needed.invalid says...
>
> 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.
>
> *******

I am impressed, and moved, by the effort you are willing to go to in
order to help an absolute (and clueless) stranger. Thank you most
sincerely.
I searched the Procmon output from 1:06 to a little past 1:08, the time
of the error. It's not quite like looking for the proverbial needle in a
haystack, because that presupposes the searcher knows what a needle
actually looks like: I'm looking for something in a haystack but I don't
know what.
I found lots of entries for SChannel very early on, up to 1:06:02, all of
them SUCCESS, but nothing after that. There are 3 successive entries for
Catalog9, at 1:06:39, with Result: SUCCESS, SUCCESS, NAME NOT FOUND, in
that order (apart from this, Catalog9 does not occur again). Is that of
any help?

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

--

Norman B. Grover
Jerusalem, Israel

On 26/09/2021 12:28, Norman B. Grover wrote:
>
> I found lots of entries for SChannel very early on, up to 1:06:02, all of
> them SUCCESS, but nothing after that. There are 3 successive entries for
> Catalog9, at 1:06:39, with Result: SUCCESS, SUCCESS, NAME NOT FOUND, in
> that order (apart from this, Catalog9 does not occur again). Is that of
> any help?

I've only been following this thread very casually, so forgive my
intervention if it's not helpful. In the paragraph above, concentrate
on the NAME NOT FOUND part. See what you can find out about what could
be causing that.

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Java Jive wrote:
> On 26/09/2021 12:28, Norman B. Grover wrote:
>>
>> I found lots of entries for SChannel very early on, up to 1:06:02, all of
>> them SUCCESS, but nothing after that. There are 3 successive entries for
>> Catalog9, at 1:06:39, with Result: SUCCESS, SUCCESS, NAME NOT FOUND, in
>> that order (apart from this, Catalog9 does not occur again). Is that of
>> any help?
>
> I've only been following this thread very casually, so forgive my
> intervention if it's not helpful. In the paragraph above, concentrate
> on the NAME NOT FOUND part. See what you can find out about what could
> be causing that.
>

Items like that in a trace, happen all the time, and
are a normal part of code flow.

The written code can be built to handle multiple situations.
(Like perhaps, have code for handling domain behavior versus
home behavior.) When a test fails in ProcMon output, this
is an entirely normal winnowing out of detail.

Analyzing those then, is very much context sensitive. If a
process that never throws such a thing, is seen to do that,
you might be "alarmed". But some sequences, you'll find more
failure cases than success cases. Testing the registry can
be like that - if some optional key is not present
in the registry (the high frequency case), then you'd be all
the time seeing that one.

What I don't understand, is why Normans OS makes these
SChannel references so willingly. I'm having trouble
getting anything out of the trace here. That's why I was
trying to dig up tools that would poke at the corners
of things, to elicit responses that would work better
as needles in haystack. But for some reason, my OS
is "sullen", and refuses to perform pet tricks on command.

What I was hoping might be present, is

5:59 ...

6:00 mystery.exe uses some protocol choice, by reading registry.

Moments later, something related to SChannel logging a
problem, is seen in procmon output.

The six hour time constant, sounds like a scheduled action.

An example of a process that keeps its own time, is NTP
for timekeeping. It wakes up every 15 minutes and makes
a log entry in the optional logging file. You set the
amount of time between major updates (like, a week),
and it contacts time.gov or similar for an update. That
isn't an entry on scheduled tasks, because W32TM is probably
setting timer events or using sleep(X) calls to use
the system timer to tell it when to run the code again.

The thing with the six hour time constant, could be
Scheduled Tasks based. But it could be any number of
other support processes, which don't know any better
and just take orders. It could easily be some
constantly running process doing it.

Paul

In article <sippv4$i4o$1@dont-email.me>, nospam@needed.invalid says...
>
> Java Jive wrote:
> > On 26/09/2021 12:28, Norman B. Grover wrote:
> >>
> >> I found lots of entries for SChannel very early on, up to 1:06:02, all of
> >> them SUCCESS, but nothing after that. There are 3 successive entries for
> >> Catalog9, at 1:06:39, with Result: SUCCESS, SUCCESS, NAME NOT FOUND, in
> >> that order (apart from this, Catalog9 does not occur again). Is that of
> >> any help?
> >
> > I've only been following this thread very casually, so forgive my
> > intervention if it's not helpful. In the paragraph above, concentrate
> > on the NAME NOT FOUND part. See what you can find out about what could
> > be causing that.
> >
>
> Items like that in a trace, happen all the time, and
> are a normal part of code flow.
>
> The written code can be built to handle multiple situations.
> (Like perhaps, have code for handling domain behavior versus
> home behavior.) When a test fails in ProcMon output, this
> is an entirely normal winnowing out of detail.
>
> Analyzing those then, is very much context sensitive. If a
> process that never throws such a thing, is seen to do that,
> you might be "alarmed". But some sequences, you'll find more
> failure cases than success cases. Testing the registry can
> be like that - if some optional key is not present
> in the registry (the high frequency case), then you'd be all
> the time seeing that one.
>
> What I don't understand, is why Normans OS makes these
> SChannel references so willingly. I'm having trouble
> getting anything out of the trace here. That's why I was
> trying to dig up tools that would poke at the corners
> of things, to elicit responses that would work better
> as needles in haystack. But for some reason, my OS
> is "sullen", and refuses to perform pet tricks on command.
>
> What I was hoping might be present, is
>
> 5:59 ...
>
> 6:00 mystery.exe uses some protocol choice, by reading registry.
>
> Moments later, something related to SChannel logging a
> problem, is seen in procmon output.
>
> The six hour time constant, sounds like a scheduled action.
>
> An example of a process that keeps its own time, is NTP
> for timekeeping. It wakes up every 15 minutes and makes
> a log entry in the optional logging file. You set the
> amount of time between major updates (like, a week),
> and it contacts time.gov or similar for an update. That
> isn't an entry on scheduled tasks, because W32TM is probably
> setting timer events or using sleep(X) calls to use
> the system timer to tell it when to run the code again.
>
> The thing with the six hour time constant, could be
> Scheduled Tasks based. But it could be any number of
> other support processes, which don't know any better
> and just take orders. It could easily be some
> constantly running process doing it.
>
> Paul

The Event Viewer displayed the error40 at 1:08, and in Procmon I recorded
from 1:06 to 1:10.
SChannel appears only up to 1:06:02 (all SUCCESS), nothing at all after
that.
Catalog9 first shows up only after SChannel, at 1:06:39; that, it would
seem lets it off the hook, despite its NAME NOT FOUND.

It is of course possible that I may not have begun recording early
enough, and that there is a Catalog9 event before 1:06:0. How much can I
stretch your 'Moments later'?

Would monitoring another 4min period containing the error40 be of any
diagnostic value?

As for the Task Scheduler, it contains a great deal of stuff, most of
which make fascinating if unintelligible reading, nothing with a repeat
period even remotely approaching 6hr.

Is it time for me to give up?

--

Norman B. Grover
Jerusalem, Israel

On 27/09/2021 12:27, Norman B. Grover wrote:
>
> The Event Viewer displayed the error40 at 1:08, and in Procmon I recorded
> from 1:06 to 1:10.
> SChannel appears only up to 1:06:02 (all SUCCESS), nothing at all after
> that.
> Catalog9 first shows up only after SChannel, at 1:06:39; that, it would
> seem lets it off the hook, despite its NAME NOT FOUND.
>
> It is of course possible that I may not have begun recording early
> enough, and that there is a Catalog9 event before 1:06:0. How much can I
> stretch your 'Moments later'?
>
> Would monitoring another 4min period containing the error40 be of any
> diagnostic value?
>
> As for the Task Scheduler, it contains a great deal of stuff, most of
> which make fascinating if unintelligible reading, nothing with a repeat
> period even remotely approaching 6hr.
>
> Is it time for me to give up?

That's entirely up to you. Sometimes I just do that, sometimes
something is irritating or even worrying enough that I feel I must carry
on. For myself, I think I would be sufficiently concerned about an
error on SChannel to want to find out exactly what is causing it ...

The basic problem here is lack of information. There are a number of
ways of approaching that, the most systematic and thorough of which is
outlined below, but let's start by restating what I think we know -
from my rereading of the entire thread just now, it seems pitifully little:

1) Every 6 hours: SChannel Error 40, Event ID: 36887, Catalog9
may be involved.

2) System clock apparently not used to time this.

3) AV software is in the clear.

Is it really as little as that, or have I missed something important?

If it really is that little, then clearly we need more information ...

Attempts to obtain targetted information pointing to a culprit using
tools like ProcMon have failed to identify the culprit, so the only
thing left is to eliminate possible suspects systematically. To do
that, first we need a list of suspects. Immediately after the next
6-hourly error, start Task Manager as an Administrator, click the
'Processes' tab, select 'Show processes from all users', and click
'Image name'. Drag the top and the bottom of its window borders to
extend it as much as possible, and drag the RHS out to allow the columns
to be expanded sufficiently to show all relevant detail. Take an
<Alt-PrintScreen>, paste the image into Paint, and save it. If
necessary scroll the list down and repeat as often as is necessary to
obtain a list of all processes running. Print these images, so you can
tick off processes as you eliminate them.

About ten minutes before the next 6-hourly error is due, close down all
processes that you reasonably can - close all the windows on the
desktop, and anything in the System Tray that will allow you to close
it. Comparing with your printed lists, put a question mark against all
processes still running.

Does the error repeat on time?

If yes, trouble, possibly big trouble. You need to start looking for
things like software update processes (mostly benign but if this is one
it's obviously going wrong, so why not disable it and update manually),
but also rootkits and malware (obviously not benign) and be sure that
you have nothing like the latter running. There is a group of tools
from SysInternals that I used to use on XP for this sort of thing, but I
have no idea how many of them are still extant for more recent versions
of Windows. One of them was 'Rootkit Revealer' which would show any
rootkits running on your system, and the other, IIRC, was AutoRuns,
which enabled you to control which processes are launched as part of
Windows, and control whether they are allowed to start or not. I'm
sorry I don't have more up-to-date information on these tools, but
hopefully others like Paul will be able to be more helpful.

If, as I hope and suspect, no, that's a relief, because it makes things
much easier. We now know that the culprit lies amongst the things you
closed down beforehand, and can use a binary chop method to nail it down
to a given one. First put a cross against all the items in the list
that had question marks, because now you know that it's not any of them.

Restart all the processes you previously stopped by re-launching all the
applications that gave rise to them, using your printouts to ensure that
as exactly as possible the tasks running are the same as before, and
about 10 minutes before the next 6-hourly error is due, which, note, may
now be 6-hours after re-launch, not the last error 40, this time close
down only what you can from the top half of the list. If the error
still does not occur, it was coming from one of these applications in
the top part of the list which you have again closed down, but if it
occurs, it's an application from the bottom half of the list which is
still running. So now you know which half of the list it lies in, and
can put crosses against the remaining applications from the other half.
Rinse and repeat: for whichever part of the list, top or bottom, that
contains the error-causing process, half that half again, in other
words, relaunch everything, just before the error is due close down that
half of half, and so on. Within about 6 iterations of this, halving the
portion of the list every time and choosing which half to close down
depending on whether or not the error was contained in your previous
effort, you should be able to nail it.

Addendum: Possibly this SChannel tutorial may prove useful along the
way, you could read it while you're waiting for the next 6 hours ...

https://argonsys.com/microsoft-cloud/library/demystifying-schannel/

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Norman B. Grover wrote:

>
> The Event Viewer displayed the error40 at 1:08, and in Procmon I recorded
> from 1:06 to 1:10.
> SChannel appears only up to 1:06:02 (all SUCCESS), nothing at all after
> that.
> Catalog9 first shows up only after SChannel, at 1:06:39; that, it would
> seem lets it off the hook, despite its NAME NOT FOUND.
>
> It is of course possible that I may not have begun recording early
> enough, and that there is a Catalog9 event before 1:06:0. How much can I
> stretch your 'Moments later'?
>
> Would monitoring another 4min period containing the error40 be of any
> diagnostic value?
>
> As for the Task Scheduler, it contains a great deal of stuff, most of
> which make fascinating if unintelligible reading, nothing with a repeat
> period even remotely approaching 6hr.
>
> Is it time for me to give up?

Some of the references I can find, seem to relate to the
usage of SChannel with an onboard web server like IIS.
Someone attempts to contact IIS on your machine,
and negotiation is unsuccessful via trying a bunch
of protocol suite values.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
EventLogging DWORD 128 # log all, default is 1

The default value of logging of "1", should log errors only.
Versus warnings or informational messages. I switched mine
to 128, and I still could not coax a message out of it.
But I also haven't installed IIS either.

This guy, might be the thing doing the logging.
But so far, that doesn't make any difference to
anything at the moment. I'm not expecting to
see this in ProcMon. The reason I was looking for
this, is to see whether SChannel logs directly.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\System\Schannel
EventMessageFile REG_EXPAND_SZ %windir%\System32\lsasrv.dll

One web article says that there is a difference between
"schannel event logging" which is the above, and
"schannel logging". In schannel logging, a person uses
a checked version of the DLL and the log shows what
that piece of code shows in debug mode. That's more
of a Microsoft developer thing.

Whereas "schannel event logging" is a Release code module
not emitting informational messages in a blanket
manner. It has only the "Event Viewer" level of interface
and should only squeak when something more serious is
happening.

I would give up, unless I could think of some hints
in terms of what you've asked the machine to do, and
what software you have installed. If you had IIS or
some other (smaller) web serving product installed,
perhaps that is what is inadvertently logging some
incoming activity of a sort. But, you'd probably
remember Port Forwarding some activity from the
WAN side, to your machine and a web or SFTP service
of some sort.

On a couple of occasions while Googling, I received
references to some Microsoft package you install to
"disable RC protocols on a machine". So that TLS 1.1 or
TLS 1.2 only uses the higher quality parts of the suite.
And doing that, seems to bear some part in making the
SChannel emit more messages. With the entire suite of
protocols left unmolested, even someone using IE6 to
contact the web server on your machine, would get
a usable response.

It's when you crank up the security level on the machine
(by disabling RC40 say), that more weird messages
could be a side effect.

I was unsuccessful at getting an event here using
outgoing (client) tests. And have not set up a
server test (it's been a long time since my
last IIS attempt).

Paul

On 27/09/2021 15:44, Java Jive wrote:
>
> Addendum:  Possibly this SChannel tutorial may prove useful along the
> way, you could read it while you're waiting for the next 6 hours ...
>
> https://argonsys.com/microsoft-cloud/library/demystifying-schannel/

Ah! The original TechNet version seems somewhat better illustrated,
depending on your browser settings:

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/demystifying-schannel/ba-p/259233

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

On 27/09/2021 20:27, Java Jive wrote:
> On 27/09/2021 15:44, Java Jive wrote:
>>
>> Addendum:  Possibly this SChannel tutorial may prove useful along the
>> way, you could read it while you're waiting for the next 6 hours ...
>>
>> https://argonsys.com/microsoft-cloud/library/demystifying-schannel/
>
> Ah!  The original TechNet version seems somewhat better illustrated,
> depending on your browser settings:
>
> https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/demystifying-schannel/ba-p/259233

More TechNet documentation:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn786445(v=ws.11)

Schannel Events

Event ID 36887: A Fatal Alert Was Received

The TLS alert sub-protocol uses messages to indicate a change in status
or an error condition to the peer. There are a wide variety of alerts to
notify the peer of both normal and error conditions. Alerts are commonly
sent when the connection is closed, a message which is not valid is
received, a message cannot be decrypted, or the user cancels the
operation. The IETF specification, RFC 4346 [Link is ...

http://www.ietf.org/rfc/rfc4346.txt

....], contains descriptions of the closure alerts and error alerts.

This alert message indicates this computer received a TLS or SSL fatal
alert message from the server it was communicating or negotiating with.
The error indicates a state in the communication process, not
necessarily a problem with the application. However, the cause could be
how the application, such as a web browser, handled the communication.

The desktop app, using SCHANNEL_ALERT_TOKEN, generates a SSL or TLS
alert to be sent to the target of a call to either the
InitializeSecurityContext (Schannel) function or the
AcceptSecurityContext (Schannel) function. The two alert types are
warning and fatal. With a fatal error, the connection is closed immediately.
Event Details
Product Windows Operating
ID 36887
Source Schannel
Version 6.1

6.2
Symbolic Name SSLEVENT_RECEIVE_FATAL_ALERT

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

On 27/09/2021 18:47, Paul wrote:
>
> Some of the references I can find, seem to relate to the
> usage of SChannel with an onboard web server like IIS.
> Someone attempts to contact IIS on your machine,
> and negotiation is unsuccessful via trying a bunch
> of protocol suite values.
>
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
>
>     EventLogging DWORD 128    # log all, default is 1
>
> The default value of logging of "1", should log errors only.
> Versus warnings or informational messages. I switched mine
> to 128, and I still could not coax a message out of it.
> But I also haven't installed IIS either.

No, that would be a different Event ID, see the list of them that I've
linked elsewhere.

This is something outgoing that's failing, so most probably either an
automatic software update, or malware. Hopefully the former, because
presumably malware wouldn't normally register events, but if the latter,
hopefully the events being logged means that it's failing.

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

In article <sislc8$1p0k$1@gioia.aioe.org>, java@evij.com.invalid says...
>
> On 27/09/2021 12:27, Norman B. Grover wrote:
> >
> > The Event Viewer displayed the error40 at 1:08, and in Procmon I recorded
> > from 1:06 to 1:10.
> > SChannel appears only up to 1:06:02 (all SUCCESS), nothing at all after
> > that.
> > Catalog9 first shows up only after SChannel, at 1:06:39; that, it would
> > seem lets it off the hook, despite its NAME NOT FOUND.
> >
> > It is of course possible that I may not have begun recording early
> > enough, and that there is a Catalog9 event before 1:06:0. How much can I
> > stretch your 'Moments later'?
> >
> > Would monitoring another 4min period containing the error40 be of any
> > diagnostic value?
> >
> > As for the Task Scheduler, it contains a great deal of stuff, most of
> > which make fascinating if unintelligible reading, nothing with a repeat
> > period even remotely approaching 6hr.
> >
> > Is it time for me to give up?
>
> That's entirely up to you. Sometimes I just do that, sometimes
> something is irritating or even worrying enough that I feel I must carry
> on. For myself, I think I would be sufficiently concerned about an
> error on SChannel to want to find out exactly what is causing it ...
>
> The basic problem here is lack of information. There are a number of
> ways of approaching that, the most systematic and thorough of which is
> outlined below, but let's start by restating what I think we know -
> from my rereading of the entire thread just now, it seems pitifully little:
>
> 1) Every 6 hours: SChannel Error 40, Event ID: 36887, Catalog9
> may be involved.
>
> 2) System clock apparently not used to time this.
>
> 3) AV software is in the clear.
>
> Is it really as little as that, or have I missed something important?
>
> If it really is that little, then clearly we need more information ...
>
> Attempts to obtain targetted information pointing to a culprit using
> tools like ProcMon have failed to identify the culprit, so the only
> thing left is to eliminate possible suspects systematically. To do
> that, first we need a list of suspects. Immediately after the next
> 6-hourly error, start Task Manager as an Administrator, click the
> 'Processes' tab, select 'Show processes from all users', and click
> 'Image name'. Drag the top and the bottom of its window borders to
> extend it as much as possible, and drag the RHS out to allow the columns
> to be expanded sufficiently to show all relevant detail. Take an
> <Alt-PrintScreen>, paste the image into Paint, and save it. If
> necessary scroll the list down and repeat as often as is necessary to
> obtain a list of all processes running. Print these images, so you can
> tick off processes as you eliminate them.
>
> About ten minutes before the next 6-hourly error is due, close down all
> processes that you reasonably can - close all the windows on the
> desktop, and anything in the System Tray that will allow you to close
> it. Comparing with your printed lists, put a question mark against all
> processes still running.
>
> Does the error repeat on time?

Yes, exactly on time (6h0m2s).

I have two machines, one at work, the other at home. Their hardware is
identical (except for a backup ups at work), their software very nearly
so. Only the work machine produces error 40.

I thought I'd compare the Task Manager Processes at home to the ones at
work just before the error is generated; if ending all the extra ones at
work affects the error repeat time, then I can proceed to narrow the
culprit down via the binary chop method you describe. Is that reasonable?
> If yes, trouble, possibly big trouble. You need to start looking for
> things like software update processes (mostly benign but if this is one
> it's obviously going wrong, so why not disable it and update manually),
> but also rootkits and malware (obviously not benign) and be sure that
> you have nothing like the latter running. There is a group of tools
> from SysInternals that I used to use on XP for this sort of thing, but I
> have no idea how many of them are still extant for more recent versions
> of Windows. One of them was 'Rootkit Revealer' which would show any
> rootkits running on your system, and the other, IIRC, was AutoRuns,
> which enabled you to control which processes are launched as part of
> Windows, and control whether they are allowed to start or not. I'm
> sorry I don't have more up-to-date information on these tools, but
> hopefully others like Paul will be able to be more helpful.

Rootkit Revealer does not run under Windows 7 X64, but I check for root-
kits regularly (manually, using MalwareBytes), and have not found any in
a long while. AutoRuns seems to work on my machine, and produces lots and
lots of stuff. I'm going to try the Home-Work comparison first, it seems
so much easier.

--

Norman B. Grover
Jerusalem, Israel

On 29/09/2021 09:02, Norman B. Grover wrote:
> In article <sislc8$1p0k$1@gioia.aioe.org>, java@evij.com.invalid says...
>>
>> On 27/09/2021 12:27, Norman B. Grover wrote:
>>>
>>> The Event Viewer displayed the error40 at 1:08, and in Procmon I recorded
>>> from 1:06 to 1:10.
>>> SChannel appears only up to 1:06:02 (all SUCCESS), nothing at all after
>>> that.
>>> Catalog9 first shows up only after SChannel, at 1:06:39; that, it would
>>> seem lets it off the hook, despite its NAME NOT FOUND.
>>>
>>> It is of course possible that I may not have begun recording early
>>> enough, and that there is a Catalog9 event before 1:06:0. How much can I
>>> stretch your 'Moments later'?
>>>
>>> Would monitoring another 4min period containing the error40 be of any
>>> diagnostic value?
>>>
>>> As for the Task Scheduler, it contains a great deal of stuff, most of
>>> which make fascinating if unintelligible reading, nothing with a repeat
>>> period even remotely approaching 6hr.
>>>
>>> Is it time for me to give up?
>>
>> That's entirely up to you. Sometimes I just do that, sometimes
>> something is irritating or even worrying enough that I feel I must carry
>> on. For myself, I think I would be sufficiently concerned about an
>> error on SChannel to want to find out exactly what is causing it ...
>>
>> The basic problem here is lack of information. There are a number of
>> ways of approaching that, the most systematic and thorough of which is
>> outlined below, but let's start by restating what I think we know -
>> from my rereading of the entire thread just now, it seems pitifully little:
>>
>> 1) Every 6 hours: SChannel Error 40, Event ID: 36887, Catalog9
>> may be involved.
>>
>> 2) System clock apparently not used to time this.
>>
>> 3) AV software is in the clear.
>>
>> Is it really as little as that, or have I missed something important?
>>
>> If it really is that little, then clearly we need more information ...
>>
>> Attempts to obtain targetted information pointing to a culprit using
>> tools like ProcMon have failed to identify the culprit, so the only
>> thing left is to eliminate possible suspects systematically. To do
>> that, first we need a list of suspects. Immediately after the next
>> 6-hourly error, start Task Manager as an Administrator, click the
>> 'Processes' tab, select 'Show processes from all users', and click
>> 'Image name'. Drag the top and the bottom of its window borders to
>> extend it as much as possible, and drag the RHS out to allow the columns
>> to be expanded sufficiently to show all relevant detail. Take an
>> <Alt-PrintScreen>, paste the image into Paint, and save it. If
>> necessary scroll the list down and repeat as often as is necessary to
>> obtain a list of all processes running. Print these images, so you can
>> tick off processes as you eliminate them.
>>
>> About ten minutes before the next 6-hourly error is due, close down all
>> processes that you reasonably can - close all the windows on the
>> desktop, and anything in the System Tray that will allow you to close
>> it. Comparing with your printed lists, put a question mark against all
>> processes still running.
>>
>> Does the error repeat on time?
>
> Yes, exactly on time (6h0m2s).

Oh, that could be serious, that means it's in the stuff loaded by
system, not stuff you yourself have launched.

> I have two machines, one at work, the other at home. Their hardware is
> identical (except for a backup ups at work), their software very nearly
> so. Only the work machine produces error 40.
>
> I thought I'd compare the Task Manager Processes at home to the ones at
> work just before the error is generated; if ending all the extra ones at
> work affects the error repeat time, then I can proceed to narrow the
> culprit down via the binary chop method you describe. Is that reasonable?

Yes, I didn't realise that you had another similar machine to compare
with, that may make life a lot easier.

If I've understood what you report above, the error still occurs with
all the desktop applications closed down, that means it's something
loaded on startup by the system. That may, but not necessarily, make it
more difficult to track down, because if you close some system processes
down, the whole machines stops or reboots.

When comparing the two machines, look particularly for:
* As you suggest, differences in the processes running;
* Particularly look for processes started by AutoRuns, particularly
things like installed software trying to self-update.

>> If yes, trouble, possibly big trouble. You need to start looking for
>> things like software update processes (mostly benign but if this is one
>> it's obviously going wrong, so why not disable it and update manually),
>> but also rootkits and malware (obviously not benign) and be sure that
>> you have nothing like the latter running. There is a group of tools
>> from SysInternals that I used to use on XP for this sort of thing, but I
>> have no idea how many of them are still extant for more recent versions
>> of Windows. One of them was 'Rootkit Revealer' which would show any
>> rootkits running on your system, and the other, IIRC, was AutoRuns,
>> which enabled you to control which processes are launched as part of
>> Windows, and control whether they are allowed to start or not. I'm
>> sorry I don't have more up-to-date information on these tools, but
>> hopefully others like Paul will be able to be more helpful.
>
> Rootkit Revealer does not run under Windows 7 X64, but I check for root-
> kits regularly (manually, using MalwareBytes), and have not found any in
> a long while.

Does MalwareBytes find rootkits? I'm not sure that it does, but others
may be able to comment further.

> AutoRuns seems to work on my machine, and produces lots and
> lots of stuff. I'm going to try the Home-Work comparison first, it seems
> so much easier.

Also compare the AutoRuns outputs on each, that may well be quite
informative.

Although comparing the two PCs is definitely a good idea, be aware of
the possibility that potentially they both could exhibit the same issue,
but the home one doesn't because the networking constraints are more
lax. What I mean is that whatever is causing the SChannel error 40 may
also be happening on your home PC, but your home network does nothing to
block it, while your work network is likely to have more tightly
controlled firewalls, which may be causing the error by not allowing
error causing traffic through.

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

In article <sj1kkv$1do1$1@gioia.aioe.org>, java@evij.com.invalid says...
>
> On 29/09/2021 09:02, Norman B. Grover wrote:
> > In article <sislc8$1p0k$1@gioia.aioe.org>, java@evij.com.invalid says...
> >>
> >> On 27/09/2021 12:27, Norman B. Grover wrote:
> >>>
> >>> The Event Viewer displayed the error40 at 1:08, and in Procmon I recorded
> >>> from 1:06 to 1:10.
> >>> SChannel appears only up to 1:06:02 (all SUCCESS), nothing at all after
> >>> that.
> >>> Catalog9 first shows up only after SChannel, at 1:06:39; that, it would
> >>> seem lets it off the hook, despite its NAME NOT FOUND.
> >>>
> >>> It is of course possible that I may not have begun recording early
> >>> enough, and that there is a Catalog9 event before 1:06:0. How much can I
> >>> stretch your 'Moments later'?
> >>>
> >>> Would monitoring another 4min period containing the error40 be of any
> >>> diagnostic value?
> >>>
> >>> As for the Task Scheduler, it contains a great deal of stuff, most of
> >>> which make fascinating if unintelligible reading, nothing with a repeat
> >>> period even remotely approaching 6hr.
> >>>
> >>> Is it time for me to give up?
> >>
> >> That's entirely up to you. Sometimes I just do that, sometimes
> >> something is irritating or even worrying enough that I feel I must carry
> >> on. For myself, I think I would be sufficiently concerned about an
> >> error on SChannel to want to find out exactly what is causing it ...
> >>
> >> The basic problem here is lack of information. There are a number of
> >> ways of approaching that, the most systematic and thorough of which is
> >> outlined below, but let's start by restating what I think we know -
> >> from my rereading of the entire thread just now, it seems pitifully little:
> >>
> >> 1) Every 6 hours: SChannel Error 40, Event ID: 36887, Catalog9
> >> may be involved.
> >>
> >> 2) System clock apparently not used to time this.
> >>
> >> 3) AV software is in the clear.
> >>
> >> Is it really as little as that, or have I missed something important?
> >>
> >> If it really is that little, then clearly we need more information ...
> >>
> >> Attempts to obtain targetted information pointing to a culprit using
> >> tools like ProcMon have failed to identify the culprit, so the only
> >> thing left is to eliminate possible suspects systematically. To do
> >> that, first we need a list of suspects. Immediately after the next
> >> 6-hourly error, start Task Manager as an Administrator, click the
> >> 'Processes' tab, select 'Show processes from all users', and click
> >> 'Image name'. Drag the top and the bottom of its window borders to
> >> extend it as much as possible, and drag the RHS out to allow the columns
> >> to be expanded sufficiently to show all relevant detail. Take an
> >> <Alt-PrintScreen>, paste the image into Paint, and save it. If
> >> necessary scroll the list down and repeat as often as is necessary to
> >> obtain a list of all processes running. Print these images, so you can
> >> tick off processes as you eliminate them.
> >>
> >> About ten minutes before the next 6-hourly error is due, close down all
> >> processes that you reasonably can - close all the windows on the
> >> desktop, and anything in the System Tray that will allow you to close
> >> it. Comparing with your printed lists, put a question mark against all
> >> processes still running.
> >>
> >> Does the error repeat on time?
> >
> > Yes, exactly on time (6h0m2s).
>
> Oh, that could be serious, that means it's in the stuff loaded by
> system, not stuff you yourself have launched.
>
> > I have two machines, one at work, the other at home. Their hardware is
> > identical (except for a backup ups at work), their software very nearly
> > so. Only the work machine produces error 40.
> >
> > I thought I'd compare the Task Manager Processes at home to the ones at
> > work just before the error is generated; if ending all the extra ones at
> > work affects the error repeat time, then I can proceed to narrow the
> > culprit down via the binary chop method you describe. Is that reasonable?
>
> Yes, I didn't realise that you had another similar machine to compare
> with, that may make life a lot easier.
>
> If I've understood what you report above, the error still occurs with
> all the desktop applications closed down, that means it's something
> loaded on startup by the system. That may, but not necessarily, make it
> more difficult to track down, because if you close some system processes
> down, the whole machines stops or reboots.
>
> When comparing the two machines, look particularly for:
> * As you suggest, differences in the processes running;
> * Particularly look for processes started by AutoRuns, particularly
> things like installed software trying to self-update.

I didn't mention my home machine before because it has been giving me
trouble lately, to the point where I don't completely trust it and have
come to believe that the system disk is dying (this has not happened to
me since the system disk was a floppy, many years ago). Still, I decided
to give the comparison a go and BINGO! up popped something called
Mail.Ru: it was listed in the Task Manager at work but not at home. A
little binary chopping showed that it and it alone was responsible for
the error-40. I found its directory on my system disk in three different
places.

Mail.Ru is listed as a Russian internet company, and what it was doing in
my machine (and how it got there) is a mystery.

>
> >> If yes, trouble, possibly big trouble. You need to start looking for
> >> things like software update processes (mostly benign but if this is one
> >> it's obviously going wrong, so why not disable it and update manually),
> >> but also rootkits and malware (obviously not benign) and be sure that
> >> you have nothing like the latter running. There is a group of tools
> >> from SysInternals that I used to use on XP for this sort of thing, but I
> >> have no idea how many of them are still extant for more recent versions
> >> of Windows. One of them was 'Rootkit Revealer' which would show any
> >> rootkits running on your system, and the other, IIRC, was AutoRuns,
> >> which enabled you to control which processes are launched as part of
> >> Windows, and control whether they are allowed to start or not. I'm
> >> sorry I don't have more up-to-date information on these tools, but
> >> hopefully others like Paul will be able to be more helpful.
> >
> > Rootkit Revealer does not run under Windows 7 X64, but I check for root-
> > kits regularly (manually, using MalwareBytes), and have not found any in
> > a long while.
>
> Does MalwareBytes find rootkits? I'm not sure that it does, but others
> may be able to comment further.

Yes it does, even the free version.

>
> > AutoRuns seems to work on my machine, and produces lots and
> > lots of stuff. I'm going to try the Home-Work comparison first, it seems
> > so much easier.
>
> Also compare the AutoRuns outputs on each, that may well be quite
> informative.
>
> Although comparing the two PCs is definitely a good idea, be aware of
> the possibility that potentially they both could exhibit the same issue,
> but the home one doesn't because the networking constraints are more
> lax. What I mean is that whatever is causing the SChannel error 40 may
> also be happening on your home PC, but your home network does nothing to
> block it, while your work network is likely to have more tightly
> controlled firewalls, which may be causing the error by not allowing
> error causing traffic through.

A simple search for Mail.Ru on my home machine didn't turn up anything.

I'm satisfied that I found the culprit, and will now turn to repairing my
home machine. Thank you Java Jive and Paul for all the time you devoted
to my problem. Without your help and advice I would never have resolved
the issue.

--

Norman B. Grover
Jerusalem, Israel

On 04/10/2021 11:59, Norman B. Grover wrote:
>
> In article <sj1kkv$1do1$1@gioia.aioe.org>, java@evij.com.invalid says...
>>
>> On 29/09/2021 09:02, Norman B. Grover wrote:
>>>
>>> In article <sislc8$1p0k$1@gioia.aioe.org>, java@evij.com.invalid says...
>>>>
>>>> About ten minutes before the next 6-hourly error is due, close down all
>>>> processes that you reasonably can - close all the windows on the
>>>> desktop, and anything in the System Tray that will allow you to close
>>>> it. Comparing with your printed lists, put a question mark against all
>>>> processes still running.
>>>>
>>>> Does the error repeat on time?
>>>
>>> Yes, exactly on time (6h0m2s).
>>
>> Oh, that could be serious, that means it's in the stuff loaded by
>> system, not stuff you yourself have launched.
>>
>>> I have two machines, one at work, the other at home. Their hardware is
>>> identical (except for a backup ups at work), their software very nearly
>>> so. Only the work machine produces error 40.
>>>
>>> I thought I'd compare the Task Manager Processes at home to the ones at
>>> work just before the error is generated; if ending all the extra ones at
>>> work affects the error repeat time, then I can proceed to narrow the
>>> culprit down via the binary chop method you describe. Is that reasonable?
>>
>> Yes, I didn't realise that you had another similar machine to compare
>> with, that may make life a lot easier.
>>
>> If I've understood what you report above, the error still occurs with
>> all the desktop applications closed down, that means it's something
>> loaded on startup by the system. That may, but not necessarily, make it
>> more difficult to track down, because if you close some system processes
>> down, the whole machines stops or reboots.
>>
>> When comparing the two machines, look particularly for:
>> * As you suggest, differences in the processes running;
>> * Particularly look for processes started by AutoRuns, particularly
>> things like installed software trying to self-update.
>
> I didn't mention my home machine before because it has been giving me
> trouble lately, to the point where I don't completely trust it and have
> come to believe that the system disk is dying (this has not happened to
> me since the system disk was a floppy, many years ago). Still, I decided
> to give the comparison a go and BINGO! up popped something called
> Mail.Ru: it was listed in the Task Manager at work but not at home. A
> little binary chopping showed that it and it alone was responsible for
> the error-40. I found its directory on my system disk in three different
> places.
>
> Mail.Ru is listed as a Russian internet company, and what it was doing in
> my machine (and how it got there) is a mystery.

Ugh! Sounds like malware trying to phone home. When 'fixing' it, note
done the creation date of its directory, that may give you some idea of
what you were doing at the time to have allowed it onto your machine.

>> Does MalwareBytes find rootkits? I'm not sure that it does, but others
>> may be able to comment further.
>
> Yes it does, even the free version.

I'm quite surprised by that, but perhaps AV software being that thorough
these days is why SysInternals decided not to bother to update
RootkitRevealer for newer versions of Windows.

>> Although comparing the two PCs is definitely a good idea, be aware of
>> the possibility that potentially they both could exhibit the same issue,
>> but the home one doesn't because the networking constraints are more
>> lax. What I mean is that whatever is causing the SChannel error 40 may
>> also be happening on your home PC, but your home network does nothing to
>> block it, while your work network is likely to have more tightly
>> controlled firewalls, which may be causing the error by not allowing
>> error causing traffic through.
>
> A simple search for Mail.Ru on my home machine didn't turn up anything.
>
> I'm satisfied that I found the culprit, and will now turn to repairing my
> home machine. Thank you Java Jive and Paul for all the time you devoted
> to my problem. Without your help and advice I would never have resolved
> the issue.

Glad to have helped.

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk