The Core Technologies Blog

Professional Software for Windows Services / 24×7 Operation


AlwaysUp Feature Spotlight: Restrict Your App To Specific CPUs

Restrict Your App To Specific CPUs

What is the “restrict CPUs” feature?

Modern computers feature multiple central processing units (CPUs). Those CPUs are the brains of the system — constantly coordinating hard drives, memory and other components to complete various tasks on your behalf.

While Windows does a great job of keeping your CPUs busy, seamlessly assigning tasks to each one, the operating system exposes a few levers to help you make the most of your computer. One such lever is the ability to assign an application to run on specific CPUs. Put another way, especially for the technical folks, Windows allows you to set the affinity for a process or thread.

AlwaysUp piggy-backs on the native Windows processor affinity functionality and allows you to run your application on one or more specific CPUs that you choose. Read on to find out why that “CPU pinning” may be a good thing to do.


Why should I limit my application to one or more CPUs?

For the vast majority of computer users, monkeying around with processor assignments is a bad idea. The truth is that Windows does an excellent job of scheduling work to CPUs and it’s unlikely that you will do better.

But, of course, there are exceptions. Here are a couple scenarios where constraining an application to specific CPUs makes sense.

Scenario #1: You’re running a legacy application that doesn’t support multiple CPUs

Some older applications and games were written before multi-processors became commonplace. The programmers assumed that a computer has single CPU and didn’t worry about concurrent execution, where different parts of the program run at the same time. Oh how things have changed!

Programs from that bygone era will often crash when run on modern computers with multiple processors. The only way to get them to work reliably is to limit them to running on a single CPU.

Scenario #2: Your application is a CPU hog

Some applications are built to consume all the processing power available to them. They peg all CPUs at 100% because they have a lot of work to get through!

Unfortunately those CPU-hungry programs can negatively impact other programs running on the computer. As the CPU hogs greedily gobble all the CPU cycles available, they don’t leave much time for other applications. And that results in starvation.

If you happen to be running one of those impolite applications, it may be best to assign the processor-intensive program to all but one of the CPUs. The logic is that by leaving a single CPU as “spare”, you reserve capacity for other programs to run there, unencumbered.


How do I enable the “restrict CPUs” feature in AlwaysUp?

To activate the setting in AlwaysUp:

  1. Edit your application in AlwaysUp, either by double-clicking the entry or selecting Application > Edit/View from the menu.

  2. Switch to the Extras tab.

  3. Check the Run the application on these CPU(s) box.

  4. Select one or more CPUs from the list.

  5. Save your changes.

For example, on our server with 4 CPUs, here’s how we constrained an application to the first and second processors only:

Only run the application on CPU 1 or 2

As you might expect, you won’t be able to activate the feature if your computer only has a single CPU. In that case, the Run the application on these CPU(s) option will be disabled.


How do I confirm that AlwaysUp is limiting my application to the designated CPUs?

If your application is running in AlwaysUp, you can use the Windows Task Manager to confirm that the process is limited to the CPUs you’ve chosen.

To do so:

  1. Start Task Manager.

  2. Switch to the Details tab.

  3. Find and highlight your application’s executable (*.exe) file in the list.

  4. Right-click the entry and select Set affinity to summon the Processor affinity window.

  5. Confirm that the CPUs you selected in AlwaysUp are the only ones selected.

For example, we installed Ollama as a Windows Service and limited it to running on the first two CPUs:

We restricted Ollama to two CPUs in AlwaysUp

After starting Ollama from AlwaysUp, we started Task Manager, found ollama.exe on the Details tab and selected Set affinity:

Set the affinity for Ollama.exe

The Processor affinity window confirmed that Ollama can only run on the first two CPUs:

Ollama processor affinity

What are your best tips for using this feature?

Tip #1: Only assign CPUs if you detect a problem

In the words of the distinguished Donald Knuth, “premature optimization is the root of all evil”. That is to say, it’s best to avoid making adjustments before you have evidence that that’ll be impactful.

Applying that advice to this situation, you should first run your applications without CPU restrictions. The vast majority of programs will have zero problems in that context. You should only override the default if you encounter a problem that CPU pinning is likely to fix.

The reality is that your CPU constraints may prevent Windows from making the best use of your hardware. Keep in mind that Windows is designed to automatically and dynamically assign applications on the least-busy processor — and CPU pinning can sabotage efficient scheduling.

Tip #2: Don’t limit too much

As you consider restricting where your application can run, be sure to keep performance in mind. You don’t want to make your application suffer by starving it of CPU cycles.

Even with the best of intentions, you can easily create a problem if you limit your application to fewer CPUs than it needs. For instance, your application may slow to a crawl if you constrain it to a single CPU when it demands much more.


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

AlwaysUp 16.5: Easily Install nginx as a Service, Survive Resource Leaks, and more

AlwaysUp 16.5: Easily Install nginx as a Service, Survive Resource Leaks, and more

AlwaysUp version 16.5 is out! Here’s what our team worked on in this new release.


The Application Advisor now supports the nginx web server

If you’re looking to run nginx as a Windows Service, you’re in luck. With the help of the versatile Application Advisor, you can now install nginx with a few clicks.

To take advantage of our expertise, start the Application Advisor (by selecting Application > Advisor from the menu) and choose nginx from the list of applications:

Choose nginx from the list of applications

After you click Next, AlwaysUp will ask you to for the location of your nginx.exe file. Just enter the full path and continue:

Enter the path to your nginx executable (nginx.exe)

In the next screen, AlwaysUp will ask for the location of the nginx server files:

Enter the nginx server files folder

From there, click Next and follow the straightforward prompts to complete the process. In a few seconds, you’ll have a new Windows Service that starts your nginx installation at boot and runs the web server continuously in the background.


Automatically restart your application if it’s using too many “handles”

Without getting too technical, a handle is a reference to an operating system resource. And as part of normal operation, Windows gives your application a handle whenever it does things like:

  • open a file;

  • start a thread;

  • use an icon/picture;

  • open a DLL;

  • write to the registry.

Unfortunately some applications never give those precious resources back to Windows. They just keep accumulating handles until they crash or hang.

If you’re running one of those misbehaving programs, AlwaysUp is here to help. The new “check handle count” sanity check will promptly restart your application if it hogs too many resources.

To deploy the new feature for an application already set up in AlwaysUp:

  1. Edit your application in AlwaysUp

  2. Switch to the Monitor tab

  3. Check the Whenever it fails a periodic sanity check and click the Set button on the right.

  4. In the Add Sanity Check window, select Check that your application doesn’t have too many resource handles open:

    Check that your application doesn't have too many resource handles open
  5. Next, set the maximum number of handles that your application should have open at any time:

    Set the maximum number of open resource handles

    Be careful with this setting. You don’t want to pick a value that’s too low because it will lead to unnecessary restarts.

  6. Follow the remaining, self-explanatory screens to complete the process and save your changes.

And with that new sanity check in place, AlwaysUp will monitor your application and promptly restart it if it consumes too many handles.


Other fixes & improvements

  • We added a couple of buttons to help you catch and reduce errors when entering a Windows account on the Logon tab:

    Easily reveal the password or validate your Windows account
    • Click the eye to show the password that you typed in;
    • Click the lock and AlwaysUp will check that the password works for the account you entered.
  • If you like, you can now prevent the Application Advisor from automatically popping up when you start AlwaysUp and no applications are installed. Just check the Don’t automatically launch… box when the Advisor starts up by itself:

    Don't automatically launch the Application Advisor
  • AlwaysUp now shows the CPU affinity in the “running” tooltip when the application is restricted to specific CPUs. It looks like this:

    Application CPU affinity information
  • Are you running Windows on your Mac inside a Parallels virtual machine? If you have trouble applying your registration code, please upgrade to this latest version of AlwaysUp. The problems have been fixed.

    AlwaysUp runs on Parallels Desktop

As usual, please review the release notes for the full list of features, fixes and improvements included in AlwaysUp version 16.5.


Upgrading to AlwaysUp 16.5

If you bought AlwaysUp version 15 (after December 2023), you can upgrade to version 16.5 for free. Simply download and install “over the top” to preserve your existing applications and all settings. Your registration code will continue to work as well.

If you bought AlwaysUp version 14 or earlier (before December 2023), you’ll have to purchase a discounted upgrade to use any version 16. Please purchase upgrades here — you’ll save 50% off the regular price.

See the complete upgrade policy for additional details.

Thanks for reading!

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

AlwaysUp Feature Spotlight: Automatically Reconnect Network Drives

Automatically Reconnect Network Drives

What is the “automatically reconnect network drives” feature? Why would I use it?

To answer those questions, let’s start with the basics. You can skip the next section if you already know what a network drive is and how it works.

Network drives, explained

A network drive is a drive letter that allows you to access data not stored on your computer’s hard disks.

To explain a bit more, a network drive consists of:

  1. A drive letter, in the range of A-Z, where the remote data will be available;

  2. The full UNC path of a folder on a remote computer.

For example in our company, each workstation has “P” — a network drive mapped to a shared folder on our server’s hard drive. You can see our P drive’s properties here:

The P drive is mapped

And with the P drive in place, Windows Explorer simply shows it alongside the other drives on the computer:

The P drive in Windows Explorer

So instead of typing in “\\ctc1\\data\” when working with programs and scripts, we can simply use “P:\” in its place — like other, normal folders on our machine. That’s because P is a helpful alias for the “\\ctc1\\data\” folder.

Maybe you have a “G drive” or a “W drive” at work? Those are network drives too, that share documents across your team. Aren’t they convenient?

Windows Services and network drives

By default, network drives are mapped in the context of a specific user. To say it another way, the network drives that you create are only available in your Windows account. That makes sense; not everyone may have access to the network locations that you can visit.

However, that approach creates an obstacle when AlwaysUp runs your application as LocalSystem — the default account for Windows Services. In that scenario, the drive you mapped in your account may not be visible to your application because it’s running in the LocalSystem account.

But even if you instruct AlwaysUp to run your application in a normal user account, Windows will not automatically restore your network drive letters. In that case, your application will still have access to the network location (via the UNC path), but the convenient drive letter will not be available.

AlwaysUp will restore your drive letters for you

When you enable the “automatically reconnect network drives” feature, AlwaysUp will cycle through your drive letters and restore each one. That way, the application you’re running with AlwaysUp will have full access to the network drives that it needs to do its work.

You don’t need this feature if your application doesn’t use a network drive

Of course, restoring network drives won’t do you any good if your application doesn’t use them! In that case — or even if your application uses UNC paths instead of mapped drives — you can ignore the “automatically reconnect network drives” feature. You don’t need it.


How do I activate the feature in AlwaysUp?

To tell AlwaysUp to automatically reconnect your network drives, edit your application’s entry in AlwaysUp and check this box on the Startup tab:

The option to automatically reconnect your network drives

How do I know if AlwaysUp hasn’t mapped my drive?

If AlwaysUp was unable to restore a network connection, you’ll see an error in the activity. It should show up in the activity panel (as shown in the screenshot below) or when you generate a report by selecting Application > Report Activity from the menu:

Error restoring a network drive in AlwaysUp

AlwaysUp isn’t reconnecting my drive. Help!

For unusual situations like this, we recommend troubleshooting from a command prompt launched from AlwaysUp. Follow the directions and once the command prompt comes up on your screen, change directory (CD) to the drive. Hopefully Windows will return a helpful message that sheds some light on the problem.

In some circumstances, Windows may require you to enter the password to restore the network drive. Naturally, those drives cannot be reconnected without some help. The next section presents an alternative way forward.


How do I map my drive when AlwaysUp cannot do it automatically?

If AlwaysUp fails to map your drive automatically, you should map the drive with a script and configure AlwaysUp to run that script before it launches your application. Here’s the step-by-step process:

  1. Compose a version of the NET USE command that maps your network drive.

    For example, your command may look like this if you need to provide a password to map the H drive:

    net use H: \\fileserver1\shared-documents /user:mjones [mjonespassword] /persistent:yes

    Test to ensure that your command does the trick when you run it from a prompt.

  2. Save your command to a batch file (*.bat). Be sure to protect the file from non-authorized personnel if it contains a password!

  3. Start AlwaysUp and edit your application.

  4. Switch to the Startup tab. From there, check the Run the following program/batch file option and provide the full path to the script you created in step 2:

    Map your network drive at startup
  5. Save your updates.

With that change in place, AlwaysUp will map your drive whenever it starts. And after doing that, AlwaysUp will launch your application — with your drive ready and available.


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

Q&A: How Do You Make Sure Your Software Is Secure?

What Do You Do Make Sure Your Software Is Safe/Secure?
  We’re conducting an evaluation of your software from a security perspective and have some questions that we’d like to address to ensure it meets our requirements. To start, can you please explain what your company does to make sure that your software and office infrastructure are free of viruses and malware?

— Kimberly Z.

Hi, Kimberly.

Even though we’re a tiny company, security is a big deal around here.

Most importantly, we realize that our number one job is to keep customers like you safe, and that our reputation as a trusted, secure software partner depends on doing that.

But it’s not only about protecting our commercial software. Yes, securing our code is very important, but so are the emails we send, the documents we share and the order information we collect. The truth is that all parts of our business must meet a high standard of privacy and security to fulfill our obligations to the hundreds of companies that have put their faith in us.

So let’s dig into the details of our security program to answer your questions. Here are a dozen things that we do to make sure that we are good stewards of your trust.


1. We digitally sign all our products

When you download a program over the internet, how can you be sure that it’s authentic? That it comes to you straight from the authors — and wasn’t doctored to include a virus or malware?

To make sure that you receive our applications tamper-free, we code sign all our executables. That way when you see our company information prominently displayed, you can rest assured that what you’re installing is valid and intact.

Windows will prompt you with our company information when you’re installing one of our programs:

AlwaysUp is code signed secure software

And you’ll always find our digital certificate when you view the properties of any of our secure software:

Core Technologies Consulting: Digital certificate

We should also mention that our company only deploys higher-grade Extended Validation (EV) code signing certificates, which are subject to additional validation and technical requirements. Because of their stringent requirements, only verified, legitimate companies are granted EV certificates.


2. We virus-check every software release

It’s very important to check for viruses at every stage of the software production pipeline. And, most importantly, the final product must be pristine. That’s why we engage third-party services to verify that nothing strange has crept into our software.

Virustotal — a well-respected online virus-scanning engine owned by Google — is our tool of choice in this area. We run all our applications through Virustotal — and we don’t release if it detects any oddities.

For example, you can see the results of checking Service Protector here. None of the 96 virus scanners found a problem:

Service Protector Virustotal Summary

In addition to Virustotal, we also rely on Download3K. They regularly verify our programs with popular antivirus engines, including McAfee, Avast and Avira.

As you can see below, Download3K’s Service Protector Antivirus Report shows no trouble either:

Service Protector Antivirus Report

Note that in the unusual circumstance where one of the antivirus scanners actually raises a flag with our software (or site), it usually turns out to be a false alarm. To resolve the issue, we promptly report the details to the antivirus manufacturer and they update their scanners to fix the problem. That happens once or twice a year — often after we publish a new release.


3. We’re trained in secure coding practices

We're trained in the OWASP Top Ten

Our team of senior engineers is well versed in secure coding techniques. Indeed, we’ve seen a lot of exploits over the past 20+ years!

But new threats are constantly emerging and resting on our experience is not an option.

To keep us on our toes, regular developer training focuses on the OWASP Top Ten and covers common issues like:

  • Buffer overflows
  • SQL injection
  • Input validation and sanitization
  • Cross-Site Scripting (XSS)

Everyone on the technical team must participate.


4. We review 100% of our code for security issues

We do security code reviews

With our deeper understanding of the pitfalls associated with developing secure software, all code changes must be double-checked for quality, accuracy, and security before committing the updates to our repository. Quite often, that second look identifies edge cases which we must cover prior to release, so it’s well worth the investment.


5. We keep third-party libraries up to date for security

We update third-party libraries for security

As part of good software hygiene, we regularly update third-party libraries and tools to fix relevant security vulnerabilities. All dependencies are checked at least once per year.


6. We patch our computers regularly

We patch our computers regularly

While bulletproofing our code is essential, it’s just as important to secure the supporting systems. That’s why we make it a point to apply operating system patches on a regular basis.

In general:

  1. Patches to fix critical vulnerabilities are applied as soon as possible — automatically if possible and usually within 30 days.
  2. On Linux, high, medium and low vulnerabilities are addressed as part of quarterly updates.
  3. We update Windows machines at least monthly (after Patch Tuesday).

7. We protect all our PC’s with auto-updating antivirus software

All our Windows machines are protected by Microsoft Defender Antivirus, often in conjunction with well-known anti-malware packages like Avira Free Antivirus or Malwarebytes.

Windows security virus and threat protection

Virus definition files are updated automatically and manual scans are performed at least once per year (and whenever anything suspicious happens).


8. Everyone attends annual security training

Everyone takes Data Security and Privacy training

Each year, our entire staff must attend information security training. The most recent sessions focused on the major threats and defenses relevant to online businesses, including:

  • Phishing
  • Password hygiene
  • Multi Factor Authentication (MFA)
  • Ransomware
  • Data security and privacy

Side note: If you’re looking for free, high-quality security training modules for your small business be sure to check out Cyber101.com. Their courses are friendly and concise — and the short quizzes after each module do a good job of measuring the learning.


9. We subscribe to industry security alerts

We subscribe to CISA alerts

It’s important to be aware of the threat landscape and get an early warning of what other businesses are facing. That’s why we subscribe to several well respected security sources, which keep us in the loop on cyberattacks, ransomware and much more.

Our team relies on timely alerts from:


10. We’re trained in the ISO 27001 information security framework

Certified ISO 27001:2022 ISMS Lead Implementer Training

In 2025, the chief security principal at Core Technologies Consulting completed Certified ISO 27001 ISMS Lead Implementer Training. The in-depth, 3-day course focused on designing an information security management system (ISMS) and a framework for its continual management and improvement.

The knowledge obtained from the coursework guides our corporate activities — pushing us to maintain confidentiality, integrity and accuracy in everything that we do.


11. We’ve documented (and enforce) our data privacy obligations

We've documented our privacy obligations

Core Technologies Consulting is committed to protecting your privacy. We will never sell, market or abuse your information.

In fact, the limited information we collect when you purchase our software (name and email address) is used only to process your order, notify you of your order status, and assist you after your purchase. Please see our privacy policy for additional details.


12. We’ve created an information security program

We've created an information security program

Even though we’re a tiny company, we felt that it was important to create an information security program to guide our work.

All employees and independent contractors must read, acknowledge and abide by our ISO 27001-aligned information security policy. We do that because we understand that information security decisions extend well beyond the bounds of the IT department. Everyone is responsible for security.


Hopefully this gives you a better understanding of how we infuse security best practices throughout our company. Thanks again for your question, and, of course, please be sure to get in touch if you have any other questions about our security posture or practices.

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

Essential Windows Services: Windows Time / W32Time

Windows Time Service

What is the Windows Time (W32Time) service?

The Windows Time service (W32Time) implements the Network Time Protocol (NTP) specification to synchronize the date and time of computers managed by Active Directory (AD).

It may not be obvious but keeping the clock accurate and synchronized with the rest of the domain is an essential task. That’s because modern authentication methods (like Kerberos V5) may fail when networked machines are not coordinated. As such, W32Time plays a key role on computers joined to Active Directory. Otherwise, it’s not really important.

The Windows Time service runs as LocalSystem inside the service host process, svchost.exe:

W32Time Windows Service

And because the service doesn’t need to run all the time on most systems, it’s often classified as Manual (Trigger start). In that case, it only wakes up to run if:

  1. a program or another service asks it to start, or

  2. whenever a one or more Windows “trigger” events occur.

Indeed, if you examine the trigger events with our free Service Trigger Editor utility, you will see that Windows will launch the service whenever “the computer joins a domain”:

Windows Time Service Triggers

That makes sense. When your PC joins a network, Windows Time jumps into action and synchronizes your clock if you’re connected to Active Directory. Afterwards, it stops and waits for the next network-join event or request to start. It’s a much more efficient way to operate versus starting at boot and running 24/7.


What happens if I stop W32Time?

If you’re working in a home environment or without Active Directory, not much will happen if you stop the Windows Time service. In fact, most of the time you will find that the service is idle on your computer.

And even if you’re in a corporate environment with networked PC’s, temporarily stopping W32Time should be fine. If it’s needed by a program or another service, they will simply start W32Time.


Is it OK to disable the Windows Time service?

It’s fine to disable the Windows Time service if your computer isn’t joined to Active Directory. But don’t expect a huge, CPU-saving impact because the service doesn’t spend much time running in that situation anyway.

However, if your computer is joined to Active Directory, you should keep the service active. You don’t want to have any trouble signing in to your PC!

In any case, if you insist on disabling the service you can do so the conventional way — by setting the Startup type to Disabled in the Services app:

Disable the Windows Time Service

After you make that change, no person or program will be able to start W32Time. It will be inert.

But if that’s not good enough and you really want to get rid of the service, you should run W32tm /unregister from an elevated command prompt. That command will stop the service (if necessary) and uninstall it from the list of services. Afterwards, Windows Time will be completely gone from your system.

Don’t worry; if you change your mind and the Windows Time service becomes your friend again, simply run W32tm /register to restore the service. You’ll be good to go.


Questions? Problems?

If you would like to know more about the Windows Time service, or you have a specific problem, please feel free to get in touch. We’ll do our best to help you!

Posted in Windows Services | Tagged , , , , | Leave a comment