Cross-Platform Troubleshooting Scripts for Linux and Windows

When CPU load climbs, a disk fills up or an RDP connection drops, the first step is to gather the right evidence. My Linux and Windows GitHub repositories include Bash and PowerShell scripts that can help with those initial checks. But a filename containing “fix” or “optimization” does not mean the script can safely resolve the issue automatically on every system.

The two repositories contain different toolsets. Linux commands and dependencies differ from Windows scripts; the distribution and server role also affect behavior. Before running any script, check what it reads and what it may change.

Separate checks from changes in the Linux scripts

The Linux repository includes scripts for CPU, memory, disk, networking, SSH, package updates and logs. Some only display information; others can change the system during the same run. For example, cpu_check.sh asks before stopping a high-CPU process. If you confirm, it terminates the process with kill -9.

Review ram_check.sh before running it: its threshold is defined in megabytes, while process memory is read from the percentage column. Those are different units. The script also runs a cache-clearing command unconditionally, so it should not be treated as a general-purpose memory optimizer.

disk_cleanup.sh can truncate large log files and clear the package cache. update_security.sh uses apt-get for upgrades and package removals, so it is not a general tool for every Linux distribution. Under some conditions, ssh_fix.sh can start a service and add a persistent port rule in Firewalld.

These actions can affect logs, running services or access rules. Instead of running the Linux scripts directly as root on a production server, inspect the source first and verify the effects in a test environment.

What the Windows scripts actually do

The Windows repository’s scripts are provided as separate PowerShell files. Its README lists Windows PowerShell 5.1 as the target. Some checks require administrator privileges; Active Directory operations may also need a suitable domain and AD DS or RSAT tools.

The CPU and RAM scripts measure and list processes by default. Stopping a process is opt-in with -StopTopProcess. The disk script’s -CleanTemp option removes files only from the current user’s temporary folder. The RDP script checks the service and local listener; selecting -StartService can start the service, but it does not create a firewall rule.

The BSOD script lists event records and whether dump files exist; it does not analyze dumps or repair the system automatically. The Active Directory script collects reports about replication, event logs, Group Policy and DNS; it does not correct the configuration on its own. The update script also requires the PSWindowsUpdate module. These limits are described in the repository’s README and the individual scripts.

Before you run a script

1. Confirm the operating-system version, Linux distribution and script dependencies. apt-get, firewall-cmd and a particular systemd unit are not present on every Linux system.
2. Read the source and identify any process termination, file deletion or truncation, service start, firewall change or package installation.
3. Test first in a disposable virtual machine or another environment with a backup. Prepare a rollback path before running anything in production.
4. If a Windows script supports -WhatIf, use it to inspect the target first. Do not assume Linux scripts share a common dry-run mode.
5. Remove usernames, IP addresses, domain names and other sensitive details before sharing logs or reports.

These repositories are starting points for initial checks and script examples. Because some of the current Linux scripts make direct system changes, do not treat them as a ready-to-run automation suite for production without reviewing them first. Explore the source or contribute through the Linux repository and the Windows repository.