Posted onDecember 14, 2021 (Revised February 21, 2022)
In early December 2021, a severe remote code vulnerability was revealed in Apache Log4j — a very popular Java-based logging framework used by developers of web and server applications.
The vulnerability affects a broad range of services and applications on servers, making it extremely dangerous — and the latest updates for those server applications urgent! In fact, malicious actors are already hard at work exploiting the flaw.
We’re taking this issue very seriously at Core Technologies Consulting. A thorough analysis of our systems has concluded that:
Posted onDecember 13, 2021 (Revised February 21, 2022)
We have been trying to get a particular PowerShell script running as a service for some time now. I have been pulling my hair out but I think I finally found the issue and I don’t understand why it’s happening.
I am using a 64-bit PowerShell module (SqlServer). My script runs fine in the ISE, no issues. But, every time I run it from AlwaysUp it gets an error that it cannot find the module. What I finally found out is AlwaysUp is launching the 32-bit version of PowerShell and not the 64-bit version that I’m calling out. So, even though my script calls the 64-bit version of PowerShell, it’s launching the 32-bit version, which is not compatible with what I’m doing.
Here is what I have specified in AlwaysUp:
Application: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Arguments: <The full path to my PowerShell script> Start in: <The folder containing my PowerShell script>
How I’m confirming my suspicions:
I’m running the PS command [Environment]::Is64BitProcess and dumping the display to a text file. When running this command, it returns true if the instance is 64-bit, otherwise false. I confirmed this works as expected by opening both PowerShell ISEs (32/64) and the correct response was given. However, the command always returns false when running through AlwaysUp.
Any help would be greatly appreciated.
— Dustin
Hi Dustin, sorry to hear of the trouble! Thanks for doing the detective work to clearly illustrate the problem for our support team.
The issue is caused by a bit of magic that Windows performs to maintain compatibility between 32-bit and 64-bit applications. Let’s explore some special folders.
The System32, SysWOW64 and Sysnative folders
On your 64-bit system, 64-bit applications distributed with the operating system live in this folder:
C:\Windows\System32
Similarly, this folder holds the equivalent 32-bit versions of those Windows applications:
C:\Windows\SysWOW64
For example, we have the 64-bit version of powershell.exe in the System32 directory:
While the 32-bit version resides in exactly the same place under the SysWOW64 folder:
If you switch to the “Details” tab, you will see that both executables have exactly the same version number. In fact, they perform identically when run.
Now here is where the magic comes in…
When a 64-bit program launches an application under the System32 folder, Windows simply starts the application, as expected.
However, when a 32-bit program tries to run an application that lives under the System32 folder, Windows:
Replaces C:\Windows\System32 with C:\Windows\SysWOW64 in the application’s path, and
Runs the application from that SysWOW64 location.
For example, if a 32-bit program tries to start C:\Windows\System32\notepad.exe, Windows will run C:\Windows\SysWOW64\notepad.exe instead!
Windows performs this “remapping” to provide stability for 32-bit applications, which often have trouble working with 64-bit applications. Microsoft thinks it is best to ensure that legacy 32-bit programs work with a legacy “32-bit view” of the operating system. Indeed, that makes sense when maintaining backward compatibility is top-of-mind.
However, the price of that safety is that a 32-bit application can never directly invoke a 64-bit executable sitting in the System32 folder. If it tries, Windows simply rewrites the path to target the 32-bit executable instead (as mentioned in the example above).
But then how does a 32-bit program start a 64-bit system utility?
If a 32-bit program really needs to invoke a 64-bit system executable, it can do so by citing the Sysnative virtual folder.
For instance, if a 32-bit application wants to run the 64-bit version of notepad, it should invoke:
C:\Windows\Sysnative\notepad.exe
In that way, the Sysnative folder makes it possible for 32-bit programs to call 64-bit operating system utilities.
Why AlwaysUp launches the wrong version of PowerShell
AlwaysUp is a 32-bit application. As such, it is bound by the rules above.
So when AlwaysUp launches the application you provided:
Doing so will force Windows to invoke the version you want.
Fortunately AlwaysUp is perfectly fine working with 64-bit applications, so you won’t run into any compatibility issues there. Please make the change and let us know if you don’t get the desired result!
Even though we have a solution, there is one corollary we should mention…
Why can’t I see the Sysnative folder?
Curiously, if you open the File Explorer and navigate to C:\Windows\Sysnative, the operation will fail. That’s because the Sysnative folder is only accessible by 32-bit applications. 64-bit programs (like the File Explorer you started) simply cannot see that directory.
However, to prove for yourself that the folder exists for 32-bit applications, start a 32-bit command prompt by running this command:
C:\Windows\SysWoW64\cmd.exe
Magically, the Sysnative folder will be visible from there:
Posted onNovember 22, 2021 (Revised February 21, 2022)
Service Protector 8.0 was released on November 9 2021. Here are the most significant changes in this new version:
Easy to use Sanity Checks will help you keep your service running 24/7
Are you struggling with a Windows Service that says it’s running but is actually dead on its feet?
How about a network server that is supposed to accept incoming TCP/IP requests but is suddenly refusing all network connections?
Or a service that is hung and has stopped updating a log file?
Those nuanced situations — where the service is running but not actually working — can torment you and your customers who rely on the service!
Fortunately, Service Protector’s new sanity check feature is here to help.
What is a sanity check?
A sanity check is a “helper” utility that Service Protector runs to detect if a service is not functioning as expected. And whenever a sanity check detects a problem, Service Protector knows that it’s time to restart the service.
Service Protector version 8.0 supports four powerful sanity checks. They can:
Test basic TCP/IP network connectivity;
Check that a log file was recently updated;
Confirm that a web server is responding properly;
Run your own custom program to detect any kind of problem you like.
The user manual describes how to configure a sanity check. For now, let’s review a real-world scenario where a sanity check can improve reliability and uptime.
Protecting the Apache Windows Service with a sanity check
Apache is the world’s premier web server. It installs as a Windows Service, to start at boot and remain running all the time:
This step-by-step guide show how to bulletproof the Apache Windows Service with Service Protector.
Even though Apache is very reliable, customers have reported situations where the service is running but the web server refuses to serve pages. In those cases, attempting to visit a URL fails with a timeout or protocol error.
With Service Protector 8, we can deploy a sanity check to watch out for that. Here’s how:
Start by editing the Apache entry in Service Protector.
Switch to the Monitor tab. Check the Whenever it fails a periodic sanity check box and click the Set button:
In the Add Sanity Check window, choose the Check that a web server is responding properly entry and click Next:
Enter the web address you would like to monitor. If this URL is inaccessible, Service Protector will recycle Apache.
Since Apache is running on your machine, the default localhost URL will likely work:
Note that you can click Check now to run an interactive test and ensure that you have entered the correct URL.
At this point, specify how often Service Protector should fetch the URL. Every 5 minutes is enough for us:
Click Next to move on.
Finally, review the summary and click Add to record your new sanity check:
And with that sanity check in place, Service Protector will attempt to fetch the URL every 5 minutes.
If the page comes back normally, nothing will happen.
But if there is a problem fetching the page, Service Protector will quickly stop and restart the Apache Windows Service to resume normal web services.
In effect, we’ve capped Apache’s downtime at five minutes!
Service Protector is fully compatible with Windows 11
To date, Service Protector 8 has performed very well. We have detected zero incompatibilities. In fact, our testing services (including MySQL, Print Spooler and our home-grown simulators) have performed as well as they did under Windows 10.
Other fixes & improvements
We’ve improved internal logging. As a result, we’ll be able to diagnose problems and resolve thorny issues quicker.
“splwow64.exe” processes, which are spawned to aid in printing, are terminated when launched from a Windows Service.
As usual, please review the release notes for the full list of features, fixes and improvements included in Service Protector version 8.
Upgrading to Service Protector 8
If you purchased Service Protector version 7 (after January 2021), you can upgrade to version 8 for free. Simply download and install over your existing installation to preserve your existing services and all settings. For instance, your registration code will continue to work.
If you bought Service Protector version 6 or earlier (before January 2021), you will need to upgrade to use version 8. Please buy upgrades here — at a 50% discount.
Posted onNovember 12, 2021 (Revised February 4, 2023)
As announced in a succinct Tech Community blog article, Microsoft is ending support for the OneDrive desktop application on personal Windows 7, 8 and 8.1 devices in 2022. The move is all about focusing the company’s technical resources on new versions of Windows, which is an understandable goal.
In any case, if you are managing an older version of Windows and rely on OneDrive to synchronize your important files, the end is nigh. You should develop an exit strategy, pronto.
When will OneDrive stop functioning?
Here are the key dates for computers running personal editions of Windows 7, 8, and 8.1:
January 1, 2022: Non-business OnDrive installations will stop receiving updates.
March 1, 2022: OneDrive will stop syncing with the cloud.
Running OneDrive as a Service will not help
Customers running OneDrive as a Windows Service, will not be shielded from those events. While AlwaysUp will continue to ensure that your OneDrive executable starts at boot and operates 24/7, that will do you no good after March 1 2022 because OneDrive will stop copying your files to and from the cloud. In essence, your OneDrive service will become a lifeless zombie. 😮
OneDrive for Business will remain viable through 2022
Have you installed OneDrive for Business (also known as OneDrive for work or school)? If so, then the deadlines above do not apply.
But the clock is still ticking.
Support for OneDrive for Business is now aligned with the Windows lifecycle, which means that OneDrive for Business may stop functioning as early as January 2023.
Upgrade to Windows 10 or 11 to continue using OneDrive
All editions of OneDrive will remain fully supported on Windows 10 and Windows 11 — at least through 2025. Upgrading is probably the easiest way out of this predicament.
Thank you for providing MyFolders for free. It’s made everything much faster.
I recently upgraded to Windows 11 and it took me a while to find MyFolders. It doesn’t show up in the right-click menu and I had to click “Show more options”. Is there a fix for this?
— Spiro A.
Hi Spiro.
Microsoft released Windows 11 in October 2021. The shiny new operating system introduced a basket of exciting goodies, including virtual desktops, improved integration with Microsoft teams, and more.
However, there is one well meaning “improvement” that we didn’t appreciate — the hasty reconstitution of the File Explorer’s useful right-click context menu.
Dude, where did my Context Menu go?
The new, abbreviated context menu — which comes up when you right-click on your desktop or in a File Explorer window — shows only a handful of entries:
To perform an operation that is available but not listed there, you must select the Show all options entry. Doing so reveals the “full” context menu — as shown on earlier versions of Windows:
The argument Microsoft makes for changing the context menu is fairly compelling. Basically, they are concerned that the right-click menu has grown unwieldy and confusing. And as a result, Microsoft’s product designers have intervened — to protect overwhelmed users from poor organization. Commendable thinking indeed.
However, experienced users like you (us!) who are quite happy wielding the power available in the “traditional” context menu may be peeved to find out that there isn’t an obvious way to always see the full menu and avoid unnecessary clicks. That is, there is no Windows setting to say “restore the old context menu”.
But why is that a problem? Well, what you accomplished with two clicks in Windows 10 now requires three in Windows 11. And that small but annoying “tax” adds up if you use applications like MyFolders extensively.
How to re-enable the full/classic Context Menu in Windows 11 from MyFolders
MyFolders version 7.1 provides the missing setting and makes it easy for you to re-enable the “classic” context menu.
Simply:
Summon MyFolders (by right-clicking on the desktop or in a File Explorer window)
Select Show all options to show the full menu
Click the MyFolders entry and choose Re-enable the full Explorer context menu:
Click OK to complete the process. As noted, you may need to restart your machine for the change to take effect:
After you reboot, a right-click will bring up the full context menu.
Easily restore the default context menu
If you tire of the full context menu and want to return to the streamlined default, MyFolders will help there as well. Repeat the steps above, but in step 3 choose Restore the default Explorer context menu instead:
(888) 881-CORE
