-
Notifications
You must be signed in to change notification settings - Fork 0
[pull] main from amidaware:main #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
modified: scripts_staging/Build/Update TRMM agent.ps1
Water is rising
Updates + countries blocklists
… output formatting
Enhance Win_NetworkScanner.py: add response time measurement, improve…
Add server version check to Windows 11 readiness script
clean choco update logs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR is being reviewed by Cursor Bugbot
Details
Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.
To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.
| foreach ($Path in $Paths) { | ||
| If (Test-Path $Path) { | ||
| $GoodPath = $Path | ||
| $GoodPath += $Path |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Uninitialized Variable Causes Unexpected Behavior
Variable $GoodPath is used with += operator without initialization. In the original code, $GoodPath was assigned with = (overwriting), but now it uses += (appending) without being initialized first. This could cause unexpected behavior since PowerShell's += on an uninitialized variable creates different results than intended. The variable should be initialized as an empty array before the loop begins.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the final PR Bugbot will review for you during this billing cycle
Your free Bugbot reviews will reset on December 11
Details
Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.
To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.
| if ($certFileWH.NotAfter) { | ||
| if ($certFileWH.NotAfter -lt $Days) { | ||
| "$($bindsite) = $($certfileWH.FriendlyName) / $($certfileWH.thumbprint) will expire on $($certfileWH.NotAfter)" | ||
| if (certfileWH.FriendlyName) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Missing $ prefix causes invalid condition checks
The conditions if (certfileWH.FriendlyName) and if (certfileMY.FriendlyName) are missing the $ prefix for the variable names. In PowerShell, without the $ prefix, these are interpreted as attempting to call a method or type named certfileWH.FriendlyName rather than accessing the FriendlyName property of the $certFileWH and $certFileMY variables. This will cause the script to fail or always evaluate incorrectly, defaulting to the else branch regardless of whether FriendlyName is populated.
Additional Locations (1)
| } | ||
|
|
||
| if ($ErrorCount -gt 0) { | ||
| Write-Host "$ErrorCount errors occurred during the operation." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Script exits successfully even when errors occur
The script always exits with code 0 via Exit 0 at line 127, regardless of whether errors occurred during package operations. The $ErrorCount variable is incremented when operations fail and a message is printed, but the exit code doesn't reflect these failures. The script will report success to the calling system even when package installations, upgrades, or uninstalls have failed.
| } | ||
|
|
||
| if ($Mode -ne "upgrade" -and !$PackageName) { | ||
| if ($Mode -ne "update" -and !$PackageName) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Mode check inconsistent with documented functionality
The condition was changed from checking $Mode -ne "upgrade" to $Mode -ne "update", but the script has both upgrade and update modes that behave differently. The upgrade mode (line 46) upgrades all packages without requiring a package name, while update mode (line 51) requires a package name. This change causes the package name validation to skip for upgrade mode but incorrectly require it for update mode, which breaks the intended behavior where update without a package name should show available updates.
| } else { | ||
| } | ||
| else { | ||
| Write-Host "Antivirus selection: $antivirusName" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Missing exit in non-customField success path
When antivirus is found and $customField is not specified, the script outputs the antivirus information but never explicitly exits. The script then falls through without an exit code, potentially causing issues with how the calling system interprets the result. The $customField path correctly uses exit 0, but the else branch is missing an exit statement.
| Write-Output "Error(s) found in Duplicati Backup within the last 24 hours." | ||
| foreach ($event in $errorEvents) { | ||
| Write-Output "Error at $($event.TimeCreated): $($event.Message)" | ||
| Get-WinEvent -FilterHashtable @{LogName = 'Application'; ID = '202', '200', '201' } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Event query without time filter produces excessive output
The Get-WinEvent calls at lines 59, 71, and 75 have no StartTime filter, causing them to retrieve ALL events with IDs 200, 201, and 202 from the entire event log history. This could return massive amounts of data on systems with extensive logs. Worse, at line 59 this runs inside a foreach loop, so it executes once per error event, potentially querying the full history multiple times. The StartTime parameter appears to have been accidentally omitted.
Additional Locations (2)
| exit 1 | ||
| } else { | ||
| Write-Output "No bluescreen events detected in the past 24 hours." | ||
| Write-Output "No Bluescreen events detected in the past $((Get-Date) - $StartTime).Days days." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Days calculation outputs object type instead of number
The string interpolation $((Get-Date) - $StartTime).Days has incorrect syntax. The .Days property access is outside the $() sub-expression, so PowerShell will convert the TimeSpan to a string first, then append literal text .Days. The output will be something like "...in the past 1.00:00:00.Days days" instead of "...in the past 1 days". The property access needs to be inside the sub-expression: $(((Get-Date) - $StartTime).Days).
…g the percentage of FREE space available (was reporting the percentage of USED space)
Added PowerShell Scripts into WIP folder
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )
Note
Adds a large suite of Windows (and some Linux) checks, collectors, tasks, fixes, deployment/upgrade utilities, and shared snippets, plus integrations for common third-party tools.
Written by Cursor Bugbot for commit 3160e96. This will update automatically on new commits. Configure here.