This is a relatively recent symptom I'm tearing my hear out chasing, so I'm wondering if it's due to a relatively recent change in Bitdefender 2019 Total Security that might have been rolled out. I say this because the problem was NEVER EVER PRESENT before the past week or two at most. In fact I'm sure it didn't exist as recently as May 28, which is when I happened to have taken a "Gold" system image backup of my Win7 HTPC system because everything was running so perfectly for the past month or two that I didn't want to miss the opportunity to capture "perfection" and make it my fall-back conceptual emergency restart restore point, should something go south in the future.
Coincidentally, I believe a new component update to BitDefender 2019 Total Security also was pushed out on May 28 (as that was the "installed date" showing in Control Panel). I am very suspicious of some change to the firewall handling in BitDefender that has been going on since May 28, as the likely reason for my current problems this past week.
So, unexpectedly things now HAVE somehow "gone south" in the past week. In desperation I decided two days ago (June 4) to restore that May 28 "Gold" system image in hopes that "stability and perfection" would return. But I'm afraid it hasn't. I know my system was "perfect" for real on May 28, but now restoring that "Gold" system image from May 28 has not corrected my problems and gotten me back to "perfection". Instead, my recent problems persist.
So now I'm suspicious of software I really have no control over and which might be responsible for my symptoms, namely Bitdefender and its product updates (to 23.0.24.120 currently dated 6/5/2019 at 5:15PM but I think it originally came out back on May 28). I'm sure that even if I restored a system image which didn't include this latest update, that before too long the product would just automatically re-update itself to the latest version. So if there is a firewall problem in this latest version, it would continue to be present today returning within a short time, even if I restored my May 28 system image backup. In other words going back to my May 28 "Gold" backup wouldn't be accomplishing anything permanently if it is Bitdefender which is at fault. The symptom I'm fighting would return within a short time I'm sure, if in fact Bitdefender is really the culprit.
I run a Win7 HTPC using Windows Media Center as my DVR. I have four HDTV's around the house, each one connected to a WMC extender (connected via ethernet/LAN to the HTPC) in order to deliver TV content to each TV location. Each extender is a LInksys DMA2100 which has a power-on/off button. After power-on there is a "Remote Desktop Protocol (RDP)" session connection to the HTPC, which is the RDP host. Each extender is its own unique RDP userid an "remote connection" occurs at power-on. Conversely, at power-off there is a logoff/disconnect of that RDP session.
All four of the extenders can be active and running and connected to the HTPC simultaneously if I wanted to, which would therefore have four RDP sessions active simultaneously. And as each one was powered-off via its remote, that associated RDP session would disappear. Powering-on the extender would simply reinitiate a new RDP session and connection.
This is ALWAYS HOW THINGS HAVE WORKED, and is exactly how things are supposed to work.
So here's the symptom: my Windows Media Center extenders are no longer functioning properly when they are powered-off using the remote. This action should trigger a 117 "session enforcement" warning event appearing in Event Viewer, with a message of "The Media Center Extender user was abruptly disconnected". This is perfectly normal and is the counterpart to the 115 information event also appearing in Event Viewer when the extender session is started by power-on using the remote, with a message of "The Media Center Extender session was established".
What is happening since May 28 is that there is no longer a 117 event occurring at power-off, as if for some reason it appears there is no detection of the "abrupt disconnect" action.. This in turn leaves the RDP extender session "active" even after it's genuinely been powered-off by its remote. And the effect of this is that a new extender RDP session cannot be newly initiated using power-on of the remote, since the old RDP session is actually still active!! And this cannot be cleared up by any other means than a forced re-booting the HTPC, which is completely unwanted and undesirable!
Ok. Earlier tonight I decided that maybe I could solve this problem (cause still unknown) by deleting and re-adding an extender, going through the normal WMC extender setup and configuration from scratch. So I did that.
And then I reviewed the contents of Event Viewer, where I now saw that the expected 115/117 events which should be there every day (as I watch TV around my house, powering on and off the exenders) were surprisingly NOT present since May 28! But then I also realized this could surely be because of my restore a day or two ago of that "Gold" system image taken on May 28. So the Windows Event Viewer log obviously re-started from that May 28 image, obviously wiping out whatever might have naturally placed there in the past week. Nevertheless, nothing from yesterday or day appears there... no 115/117 from today.
At least not until this evening, when I did the delete/re-add of an extender, as my attempt to see if I could get things working again by a whole new extender setup (i.e. RDP user defined).
And it was in the review of the Event Viewer after tonight's delete/re-add of the extender that I noticed unexpected messages in the log regarding "firewall discovered", and "Bitdefender firewall", and what might perhaps be an indication of a problem relating to WMC extenders and their RDP connection/sessions, all stemming from something new in BitDefender's firewall processing since May 28 in the latest product version.
That's my story. I definitely have a problem. I am NOT seeing 115/117 events in the Event Viewer log since May 28, as have always been present before when I power-on/off my extenders. And because of this the RDP sessions are remaining active, and I cannot power-on and connect a second time from the same extender (since the first RDP session is still active), forcing me to re-boot the HTPC which is obviously not what I want to be doing.
One additional factoid that's relevant. It SHOULD be possible to manually terminate an RDP session using an Administrator Command Prompt window. You then "query" for any active RDP sessions using the QWINSTA command. If any extender RDP sessions have been initiated, they will show up as "active" with their session name and ID, either of which can then be used to terminate them manually.
And once the session name/ID is known, in theory that RDP session can be manually stopped using the RWINSTA command, which identifies the target RDP session to be killed either by its user name or session ID. In theory.
However the RWINSTA command IS NOT WORKING! About a minute goes by and then the command prompt line returns, as if it had taken that long to manually terminate the RDP session. But if I then do another QWINSTA I see that the extender RDP session is STILL ACTIVE AND RUNNING! In fact it has NOT been killed at all!
So, might the latest BitDefender now be "protecting" me somehow in a new way, through its newly updated firewall protections? Might it not realize that WMC extenders are perfectly normal RDP devices that want to establish RDP sessions and will eventually have an "abrupt disconnect" when the extenders are powered-off, and that the RDP sessions should be allowed to be terminated? Why can't RWINSTA manually terminate the session like it's supposed to be able to do?
I am very shortly going to uninstall BitDefender (or at least deactivate all of its protections, including firewall), just to test out my theory that this MAJOR PROBLEM with WMC extender/RDP session misbehavior is absolutely coming from BitDefender... or not.
Thoughts?