At this point I'm getting the 0xc000007b error (despite uninstalling and reinstalling all of the Visual C++ redistributables through 2022 and updating DX9 multiple times), so hopefully updating my NVidia drivers and doing a reinstall of SWTOR might do the trick.

At this point I'm almost certain it's an issue with the launcher, not the game or anyone's OS.

I made a one-time exception to disabling Windows Update to get this working. Says I already have it installed (I must have done it at some point in the past). I've been eyeing an upgrade to Windows 11 for some time, so maybe that will solve my problem when I get around to it. As for requiring an upgrade to Windows 10, that's not actually a concern of mine; SWTOR has always been geared towards reaching the most number of people/the broadest audience possible, and as of this past summer, over 70% of Windows machines run Windows 10, with Windows 7 at a distant 13% and Windows 11 at around 10%. So SWTOR trying to gear itself towards Windows 10 users is fine, but its engine and reliance on DX9 is problematic (DX9 was originally released in 2002 for WIndows ME/XP, and the Hero engine is nearly as old).

It only happens with SWTOR, not with any other games, and that update requires enabling Windows Update (the package downloaded from the Download Center gives me the 0x80070422 error, which is a Windows Update error), which is itself a security risk. I might try it and see if that fixes my specific issue, but I'm not hopeful.

That's...not exactly a solution. This now appears to be an issue with the "new" launcher, not the game or Windows 7 x64. The new launcher has been problematic since it was introduced (e.g. forcing the use of the same loading screen/constantly replacing custom loading screens, increased delays due to the launcher "searching for updates," and so on), and I am relatively certain that the 64-bit update would have worked just fine with the prior iteration of the launcher.

That's not how it works - basically you're updating already-existing DirectX 9 files (if your DX12 is an upgrade from previous versions) or installing them (if your DX12 is the only version on your machine). Programs that are written to utilize the highest-version of DirectX on your machine will still use DX12. SWTOR, on the other hand, is still written to use DX9 (an update to use higher versions of DirectX may be in the works for the distant future) and thus requires DX9 files on your machine to run.

Yes. Just out of curiosity, I ran swtor.exe (from the retailclient folder) and got this error: "The procedure entry point ucrtbase.terminate could not be located in the dynamic link library api-ms-win-crt-runtime-l1-1-0.dll" - which is not a problem that occurs with any other program/game on my machine. I have emailed support with the same information (my OS, when I patched, what happened afterwards, disabled antivirus/firewall, manually installed DirectX runtime, uninstalled and reinstalled with the same problem, uninstalled again and attempted to run the game from the copy I archived after patching this morning) and attached the complete launcher log file.

Nothing happens. I patched this morning, and after patching finished, clicking on the play button didn't start the game as usual (which normally would have taken me to the server select screen showing all servers down as I patched during maintenance). Looking online for solutions, I came across the DirectX 9 issue that corrected the problem for some people; this did not work for me (I updated it, yes). I have disabled both my firewall and my antivirus. I never ran SWTOR in compatibility mode, and I checked again to confirm this. I am running Windows 7 Pro 64-bit. For reference, this is the part of the launcher log file that I think may be relevant (in bold and in red): 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Task.7cd85b04.launch - Not waiting for process to exit 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Task.7cd85b04.launch - Successful 1 ExitCode -1073741511 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Task.7cd85b04.launch - Error - Launch_Error_UnknownCode 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Event launch completed in 0s (0) 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Dictionary.0bf857c8 - successful=false (Boolean) 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Dictionary.0bf857c8 - cancelled=false (Boolean) 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Dictionary.0bf857c8 - errors (List) 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Dictionary.04207174 - =Launch_Error_UnknownCode (String) 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Dictionary.0bf857c8 - name=launch (String) 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Dictionary.0bf857c8 - workflow=8ea8790d143c754eb269c12df329c3d4 (String) 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Dictionary.0bf857c8 - exists=true (Boolean) 03/28/2023 14:51:21 DEBUG - Workflow.8ea8790d - Dictionary.0bf857c8 - global=true (Boolean) 03/28/2023 14:51:21 CONSOLE - WorkflowManager - Event Complete - {"successful":false,"cancelled":false,"errors":["Launch_Error_UnknownCode"],"name":"launch","workflow":"8ea8790d143c754eb269c12df329c3d4","exists":true,"global":true}

"poorly thought out" I think you misunderstand - you don't need to do lots of damage. I think it's actually either damage (any damage) or objective points (i.e. sitting on a satellite). Obviously in TDMs there are no satellite objective points, so it's easier to get kicked from a TDM match. I do agree with you that the idle timer tends to penalize new/novice pilots more, as they will have a harder time landing hits and therefore getting damage in TDMs. As for "damage farmers," I don't think you understand what you're talking about. All damage in GSF is aimed at a specific objective: to help clear opposition ships/mines/drones/turrets, either in defense (e.g. a satellite or bomber nest) or offensively. Therefore, there's no damage that could be considered "bad damage" or "damage farming." If you do a lot of damage (e.g with AoE ion rail) but aren't successful enough to land the kill, you have hopefully softened up your target(s) for your teammates and will get the assist. If you're referring to pilots who continue to plug away at the same heavily-defended satellite despite never actually taking it or getting a kill, only novice pilots (or veteran pilots who know their team has zero chance of victory) will do this, and in the case of novice pilots, they will do so little damage that it can't really be called "farming." In the case of veteran pilots who queue into a lost match, they can't be blamed for doing this.

That can be corrected by changing instances (e.g. traveling to fleet or your ship) if the queue button is locked. It's happened to me a handful of times (yes, I've also been booted for going AFK during some matches; if you ask me, I think the idle timer is a little too short, and it doesn't solve the problem of SDers or people who do just enough not to get flagged for idling yet make exactly zero contribution to the match), and changing instances fixed the button lockout.

Dunno if anyone's posted about this - I don't fly (or play SWTOR) all that much anymore, but I noticed today that I couldn't link GSF stats on my toons to show a guildie who's just getting into GSF what that looks like. Has this been a thing for a while and I just didn't notice, is this a me-only problem, or is this something new?

It's not just Strongholds that I'm having issues with - I'm also unable to use legacy transport, and unable to accept GSF queue pops. Something is wrong with the game's buttons, it seems.

Don't look at me; I agree with you (and I've been inconvenienced by it as well); from what I understand some players were using legacy gear to transfer cartel market color crystals between toons in order to perform a toon-specific unlock instead of using the cartel coin method in collections to do a legacy-wide unlock, basically generating color crystals out of thin air without incurring the CC cost normally required to do so (i.e. this could be noticed as a deflationary pressure on cartel market color crystals). I agree that the devs' method of dealing this this issue is very crude. I don't know what goes into what must now be the very-convoluted SWTOR CM/collections code, but I can't imagine it would be that difficult to keep track of a variable for each CM color crystal owned by any toon in a player's legacy indicating whether or not that color crystal has been legacy-unlocked by CCs (if not, no toon on that player's legacy would be permitted to put that specific color crystal in a legacy weapon and store it in a legacy cargo hold/mail it - in effect ensuring that every player who exploited the legacy weapon to perform a toon-specific color crystal unlock on each toon would still have to pay CCs to legacy-unlock it for storage/mailing, like the rest of us have done).

Basically this has turned into a money sink for any player who's put in any collections-unlocked (i.e. legitimately unlocked using cartel coins) color crystals in legacy-bound weapons. The only viable/non-exploit workaround to the restriction is to craft your own color crystal (this of course requires that you have an artifice toon that can craft color crystals) and put that into the legacy weapon, overwriting the collections-unlocked color crystal there; buying a crafted color crystal will almost certainly be more expensive than just pulling out the collections-unlocked crystal.

These 3 things are probably my biggest pet peeves about the strongholds in general. And it's not just things that I set to 20 auto-relocating to 19 (at least on the position bar; the true position of the deco is in fact where it's supposed to be, which can be confirmed when changing its position via the X or Y orientation on the position bar as applicable), it's also things set to 15, 10, or 5 appearing to auto-relocate to 14, 9, or 4 (same for X and Y positions set to -20, -15, -10, and -5). Like I said, the true position of the deco is where it's supposed to be, but its position bar doesn't display the true/intended position correctly until the stronghold instance is reloaded. Hook symmetry (rather, the lack thereof) is noticeable, and more glaringly so on Manaan than in any other stronghold. Because this doesn't affect a decoration's true position (but is bothersome to those of us who have even the slightest hint of OCD), I consider this a minor annoyance. The intro video is a really minor annoyance, since [Esc] nips that in the bud and takes you right to where you wanted to be. The Felusia Stato deco limit of 4, however, is still in place (as mentioned in the quote, a holdover from when there were only 4 strongholds available), and now the only general-purpose vendors that don't have such a limit are the 3 deco droid vendors (industrial, synthetic, universal). Still a relatively minor annoyance. Someone else mentioned in an earlier post something about the "pick up decorations in room" feature being bugged. I can confirm that this has occurred in strongholds since at least the Yavin IV stronghold was released; at the time I attributed this to the fact that none of the Yavin IV rooms are actually separated by true doors or elevators, but then I noticed this occurring on other strongholds (e.g. NS and Tatooine) where such separations existed (and therefore the "pick up decorations in room" should only have picked up decorations within a set radius of the player's position, not all of the decorations in the entire stronghold). So yeah, this is a major irritation because it limits what players can do when they want to make minor/room-specific alterations to their decorations in excess of, say, 5-10 decos - they can't pick up the decos in the room because that button will pick up all decos in the entire stronghold, so now they're forced to individually pick up every single decoration in a room that needs to be removed/relocated, which for some stronghold rooms (think the Tatooine hangar bay, or practically any space in the Yavin IV stronghold) is a massively time-consuming process (and one that the "pick up decorations in room" button was supposed to handle).