The Core Technologies Blog

Our Software // Windows Services // 24×7 Operation


Q&A: Why can’t I open my Dropbox files even though Smart Sync is off?

Q&A: Why can't I open my Dropbox files even though Smart Sync is off?
  I just installed AlwaysUp (13.3.3.17) specifically to keep a Dropbox synchronized with a Win 2012 R2 server.

I have followed the installation guide (wizard and then double checked the setting). Smart Sync is turned off.

The service seems to start from AlwaysUp, and using Process Explorer I can see that Dropbox started with a bunch of TCP/IP connections (5 or 6) after running for a few minutes, then that drops to 3 then 2 then back to 3 connections. However, I think this is a red herring because starting "in this session" does the same.

Anyway, if I try to access one of the files from the Dropbox folder I can navigate to the file but it is "lightened" (not greyed out, but not full color). When I try to open the file, a PDF for example, I get an error that the file cannot be accessed.

The server is not the original source of the data. That is, other people modified/created files in Dropbox and the server needs to access them.

If I restart the service “in this session”, when I access a file I see a Dropbox notification that the file is being download and I have access to the file.

This situation reads like the issues reported and fixed by setting QT_OPENGL as a environment variable but I tried it and still no luck.

Dropbox is the very latest, version 139.4.4896. I’m using a paid account.

If AlwaysUp cannot keep Dropbox running/syncing in the background then it is of no use to us.

How should we proceed to fix this?

— Christopher

Hi Christopher, sorry to hear of the trouble! We have hundreds of clients running Dropbox with AlwaysUp every day so I’m sure that we’ll be able to resolve your problem soon.

What’s up with Smart Sync?

You are on the right track in disabling the Smart Sync feature. As described in this article, Smart Sync doesn’t play well with background operation, such as when you start Dropbox at boot as a Windows Service.

Based on your message, you’ve configured the Sync tab of your Dropbox Preferences window like this, right?

Disable Smart Sync for new files

That’s good, but turning off the Save hard drive space automatically option might not be enough to get rid of Smart Sync entirely. That’s because the setting only applies to new files uploaded to Dropbox.com. It’s simply the default going forward.

Most importantly, some files uploaded to dropbox.com before you turned off Smart Sync may NOT be present to your hard drive. They will remain as “online only”, and Dropbox will only be fetch them from the cloud when you first open them on your server. As a result, those “older” files will be inaccessible when you are running Dropbox as a Windows Service with AlwaysUp.

Fortunately, the problem has an easy fix. Simply instruct Dropbox to download all your files — for real.

How to make all your Dropbox files “Local” (not “Online only”)

To force Dropbox to fully download all your files to your PC, you can update the settings for each folder.

Navigate to your Dropbox directory in File Explorer, right-click a sub folder and select Smart Sync > Local from the menu:

Set Smart Sync folder to Local

However, that may be very tedious!

Your best bet is to do away with the Sync feature entirely — as guided by the Dropbox crew:

Uninstall the system extension

Note: Uninstalling the system extension will disable Smart Sync, but you’ll still be able to use the Dropbox desktop app.

To uninstall the system extension:

  1. Sign in to dropbox.com.
  2. Click your avatar (profile picture or initials) in the upper-right corner.
  3. Choose Settings.
  4. Click the General tab.
  5. Toggle Dropbox system extension to off.

Admins: Uninstall the system extension from your team’s computers

As an admin, you can uninstall the Smart Sync system extension from your team’s computers. To do so, follow this link to the uninstall page of the admin console, check the boxes, and click Uninstall.

After the system extension is uninstalled, team members can still use the Dropbox desktop app, but all of their online-only files will become local and Smart Sync will be disabled for both their team account and any linked personal account they may have.

Alternatively, you can manage your team’s default Smart Sync settings without uninstalling the system extension for your team.

And with Smart Sync deactivated, Dropbox will download all your files when its running as a Windows Service. You shouldn’t have any problems opening your files.

Happy Dropboxing!

Posted in AlwaysUp | Tagged , , , , | Leave a comment

We’re Not Affected by the December 2021 Apache Log4j Vulnerability

We're Not Affected by the Apache Log4j Vulnerability

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:

  • None of our Windows software uses Apache Log4j.

    AlwaysUp, Service Protector and our free utilities are not exposed.

  • Log4j2 <= 2.14.1 is not used by any software in our infrastructure.

    Our back end components use other logging frameworks (e.g. Monolog) to capture important messages from the server software.

  • All back end security patches have been applied.

    Our Linux application servers are configured to automatically deploy security patches as they become available.

We’ll continue to monitor the situation as it evolves.

Please be sure to reach out to our support team if you have any questions or would like additional information.

Stay safe!

Posted in Support | Tagged , , , , , | Leave a comment

Q&A: Why does AlwaysUp run the 32-bit Version of PowerShell?

Why does AlwaysUp run the 32-bit Version of PowerShell?
  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:

powershell.exe in the System32 directory

While the 32-bit version resides in exactly the same place under the SysWOW64 folder:

powershell.exe in 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:

  1. Replaces C:\Windows\System32 with C:\Windows\SysWOW64 in the application’s path, and

  2. 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:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Windows actually starts:

C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

which is the 32-bit version of PowerShell.

How to make AlwaysUp launch the 64-bit PowerShell executable

To make AlwaysUp run the 64-bit version of PowerShell, specify this value in the “Application” field:

C:\Windows\Sysnative\WindowsPowerShell\v1.0\powershell.exe

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:

32-bit CMD accessing the Sysnative folder
Posted in AlwaysUp | Tagged , , , , , , | Leave a comment

Service Protector 8 Maximizes Service Uptime with Advanced Sanity Checks

Service Protector 8: Maximize Uptime with Advanced Sanity Checks

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:

  1. Test basic TCP/IP network connectivity;

  2. Check that a log file was recently updated;

  3. Confirm that a web server is responding properly;

  4. 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:

Apache Windows Service

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:

  1. Start by editing the Apache entry in Service Protector.

  2. Switch to the Monitor tab. Check the Whenever it fails a periodic sanity check box and click the Set button:

    Set the Sanity Check
  3. In the Add Sanity Check window, choose the Check that a web server is responding properly entry and click Next:

    Check web server sanity check
  4. 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:

    Configure the web server sanity check: URL

    Note that you can click Check now to run an interactive test and ensure that you have entered the correct URL.

  5. At this point, specify how often Service Protector should fetch the URL. Every 5 minutes is enough for us:

    Configure the web server sanity check: Frequency

    Click Next to move on.

  6. Finally, review the summary and click Add to record your new sanity check:

    Add web server 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

Windows 11 Ready

Here at Core Technologies, we’ve been interrogating Windows 11 for the past few months — ever since preview builds became available via the Windows Insider program.

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.

See the complete upgrade policy for more details.

Enjoy!

Posted in Service Protector | Tagged , , , , , | Leave a comment

OneDrive Will Soon Stop Working on Windows 7, 8 and 8.1

OneDrive Will Soon Stop Working on Windows 7, 8 and 8.1

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.

However, Microsoft seems to be partially jumping the gun here. Windows 8.1 is still under extended support, until January 2023!

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.

Posted in OneDrive | Tagged , , , | Leave a comment