Sign in with
Sign up | Sign in
Your question
Solved

Problem with csrss.exe & winlogon.exe, related to NIC

Last response: in Windows XP
Share
November 26, 2011 3:09:55 AM

I seem to be having a very big problem that is bringing my system to a virtual crawl every now and then.

I have two files, csrss.exe and winlogon.exe continually launching and then being shut down. This happens only once every week or two, but when it does happen it brings my system to a virtual standstill.

I am looking at this through Process Explorer, which clearly shows the two files appearing and disappearing. Some appear and vanish within a second, others hang around for up to a minute or two. Sometimes I have up to eight files up and running that are a mix of the two (three of winlogon.exe, five of csrss.exe, for example). None show significant processor usage (and the overall system has >10% load), but somehow the system is still being brought to its knees.

The most interesting thing is that when I disable and re-enable the on-board network card, the entire problem vanishes.

I am running the SuperMicro X5DA8 with the Intel E7505 chipset, and a pair of Intel Xeon SL6YQ (D1) processors running at 2.8Ghz. I have a Radeon HD 7650 AGP graphics card with 1Gb Memory. I have 4Gb of ECC Reg DDR memory (2.56Gb usable) installed. My O/S is a very cut down version of Windows XP Professional SP3 32-bit that is heavily modified (no WMP, no OE, minimal services, etc.) and very securely locked down (it passes the vast majority of the Belarc checks). I have confirmed that my system is clean. I would be *very* surprised to see any malware on this system.

The on-board network card claims to be the Intel Pro/1000 MT card, and the driver is the Intel 8.10.3.0 from 2008-08-20. It appears to be functioning correctly (according to the management console) at all times. The device instance ID is: PCI\VEN_8086&DEV_100F&SUBSYS_10118086&REV_01\5&1F32DDE5&0&18E810

Has anyone ever come across this situation before, and how did you solve it? I am not keen on restarting my network connection every time this happens.
November 30, 2011 3:02:01 PM

Discovered the solution, but in a roundabout way.

Was checking my system logs, when I noticed an extremely large number of “hack attempts” on my machine (sometimes up to 30+ a minute) through the RDP (Remote Desktop Protocol) system. Now, I *do* need this to be up and running, because I often access my home machine from elsewhere. However, this *could* indeed be the source of that strange activity, as both csrss.exe and winlogon.exe are used during login. Plus, I double-checked Process Explorer when attached remotely, and voilà - a second set of those two processes, including a number of sub-processes under winlogon.exe (spawned when the login was successful).

Thank goodness I make use of a unique username, thank goodness that is the only account active on my machine, and thank goodness both my username and password make use of multiple extended UTF-8 characters that are NOT found on any North American keyboard. In fact, there is no keyboard layout on the planet where all the characters are found together. You have to use ALT-codes to get at least some of them no matter what keyboard layout you are using.

Paranoid? Oh, yeah.

Now, if only there was a way to get windows to “blacklist” any IP address that has more than 2 or 3 RDP connection attempts a minute… especially a blacklist method that acts as a tarpit and really hurts/slows down the process at the hacker’s end…
m
0
l
December 6, 2011 5:01:18 PM

Hey - I have been having a very similar issue - a second set of winlogon/csrss was running, and it brought my computer to a crawl due to high cpu usage. They would keep starting and stopping..

Do you think that simply disabling remote access would do the trick? Have you ever found out any additional info on the matter?
m
0
l
Related resources
December 6, 2011 6:35:22 PM

If you do not use Remote Access, then by all means disable it. It represents a potential way for any attacker to take control of your computer with as much power/rights as if s/he were sitting directly in front of it. If the computer that is seeing this activity occur is the target machine (the one you connect to using RA), then my advice below will help. If it is always the originating machine (the one you use RA to connect to other machines), then you can safely turn off RA, as it is only used when someone connects to the machine in question.

Unfortunately, there does not seem to be any way to tarpit or blacklist actual hack attempts.

The best way to preserve RA while discouraging hack attempts is to change the port that it works over. If you have only your target computer behind a firewall (the originating machine doesn’t need to be altered), this can be done either by a registry entry (google it, it’s out there) or by changing the external port on your firewalled router (the port forwarding feature on your router).

Since I make use of servers behind my firewalled router, and since I need RA access to a number of machines behind said firewall, the second method is the one I used. The 3389 port that was transparently forwarded to the internal network was the one to my main workstation, since I use that one the most. Since I have other ports open (80, 25/26, 110, other RA ports, etc.), I just changed the external port (for RA to my main machine) to 8080 (another HTTP port) to confuse potential port scanners. When I connect via RA using an external (originating) machine, I just use my router’s IP address (like before), but now I add a :8080 to the end of the IP address. The router knows to take anything coming into that port and forward it on to port 3389 on my main machine.

Since I am using the DD-WRT firmware on my router (with the expansion pack), I am currently investigating using a reverse proxy to use only a single external port to do RA connections to any number of machines behind the router. Unfortunately, it is not looking too good, as it seems that RA connections do not include an actual domain name in their connection request (something that is needed for reverse proxies to know which machine behind the router is being targeted). If they did, I could enhance security even further by using subdomains to target individual machines behind the router, and automatically rejecting all requests that do not use an approved subdomain. Too bad, that.
m
0
l

Best solution

December 6, 2011 7:06:51 PM

Very interesting - it never occurred to me that it was ACTUAL terminal connection attempts.. luckily I can disable it in this case, but the solution you describe sounds good (changing the port used)

Looks like csrss and winlogon are not starting/stopping since I disabled remote access...

Thanks so much for your info, and also for the self reply to the original post. So often people just reply saying 'never mind, figured it out' without explaining..drives me nuts :) 
Share
December 6, 2011 9:54:00 PM

It drives me nuts, too. Which is why I always try to post an answer, if I found one by myself. In fact, I can see that my previous post might have been a bit confusing… always feel free to ask more questions, just understand that I may not be able to answer immediately.
m
0
l
December 14, 2011 4:03:15 AM

Best answer selected by rekabis.
m
0
l
June 8, 2012 12:48:13 PM

It's not necessary to disable remote access completely, do only disable the Remote Assistance.
Keep the Remote Desktop Access enabled so you stiil have access to your computer remotely without this Winlogon problem.
m
0
l
October 3, 2012 9:57:40 PM

Probably one of the new worms that attack port 3389. My intrusion protection logged thousands of those til I darked out 3389. Watching at the edge device I found as many as 20 simultaneous connects from various SPOOFED IP ADDRESSES or from other compromised computers being run by a bot herder. This activity seemed to happen most between 3am and 7 am Pacific and all of the ip addresses except 1 appeared to be India or China. 1 was located in England and returned pings. On a hunch I fired up RDP and pointed to the address where I immediately was offered a login prompt to a server 2003 system. My guess is that this was a system that had been compromised by the tool attacking my network.

The bottom line here is that so far these guys point all of their attacks directly at 3389 and the thousands attempts per day died out to almost zero when I killed that port at the edge router.
m
0
l
!