Capture the next hourly write to places.sqlite with Process Monitor, identify the Firefox process and its parent or launch mechanism, and then disable that specific scheduled task, extension, service, or restored background page.
TRANSITION_RELOAD proves that Firefox recorded a reload; it does not identify what requested that reload. Firefox stores history and bookmarks in its Places database, places.sqlite, and a background or restored page can create a history record without ever becoming a visible foreground tab.^1^
1. Trace the next occurrence
- Note the exact timestamp of the latest unwanted visit.
- Run Process Monitor as administrator. It records file-system and process activity, including image paths, command lines, users, parent/child relationships, and process trees.^2^
- Press Ctrl+L and add these filters:
-
Pathends withplaces.sqlite→ Include - Optionally,
Process Nameisfirefox.exe→ Include
-
- Clear the existing capture, start capturing shortly before the next expected hourly event, and stop it immediately afterward.
- Open the matching event and record:
- PID
- User
- Process start time
- Image path
- Command line
- Select Tools → Process Tree and inspect the Firefox process:
- New Firefox process at that time: investigate its parent process or scheduled launch mechanism.
- Existing Firefox process: the reload is probably internal to that Firefox session—such as session restoration, a background/discarded tab, or an extension. Those are plausible mechanisms, not established causes.
- No matching write: remove the process-name filter and repeat, because the profile may be in a different location or another process may be touching the database.
Do not edit or delete places.sqlite while Firefox is running; that risks profile/database damage and would remove evidence without stopping the trigger.
2. If Firefox is being launched hourly
The Startup apps page is not exhaustive. Scheduled tasks, services, logon entries, Explorer add-ons, and other persistence locations are separate.
Export the complete scheduled-task inventory from an elevated Command Prompt:
mkdir C:\Temp 2>nul
schtasks /query /fo CSV /v > C:\Temp\ScheduledTasks.csv
schtasks /query /fo LIST /v > C:\Temp\ScheduledTasks.txt
findstr /i "firefox.exe http:// https://" C:\Temp\ScheduledTasks.txt
The verbose schtasks query exposes task recurrence and action details.^3^ Search the export for:
-
firefox.exe - The affected hostname or URL
- PowerShell,
cmd.exe, scripts, or URL-handler commands - Hourly or 60-minute repetition
Also check Task Scheduler → Task Scheduler Library and enable/view each candidate’s History tab. The corresponding event log is:
Event Viewer → Applications and Services Logs → Microsoft → Windows → TaskScheduler → Operational.^4^
If the task is confirmed as the trigger, disable it first rather than deleting it, wait through the next expected interval, and verify that no new visit appears.
3. Check persistence beyond Task Scheduler
Run Microsoft Sysinternals Autoruns as administrator:
- Select Options → Hide Signed Microsoft Entries.
- Use Find to search for:
-
firefox - The domain
- Any executable or script identified by Process Monitor
-
- Inspect at least Logon, Scheduled Tasks, Services, and Explorer.
- Use Jump to Entry to inspect the underlying configuration.
- Uncheck a confirmed entry to disable it reversibly; avoid deleting it until the result is validated.
Autoruns covers substantially more autostart locations than Windows Startup apps and can show entries for different user accounts.^5^
4. If Firefox was already running
Treat this as Firefox-session activity rather than Windows launching Firefox:
- Record all currently installed Firefox extensions.
- Disable nonessential extensions for one full hourly interval.
- If the entry stops, re-enable extensions in halves until the responsible extension is isolated.
- If it continues, test with a new Firefox profile for one interval, without importing extensions or restoring the previous session.
- If the clean profile does not reproduce it, the trigger is in the original profile’s session state, extension set, or configuration.
5. Last isolation step
If tracing does not identify the source, perform a Windows clean boot, test through one expected interval, and then re-enable non-Microsoft services in halves. A clean boot disables non-Microsoft services and startup items temporarily; some office functionality may be unavailable during testing.^6^
If the URL or launching executable is unexpected or untrusted, preserve the Procmon capture and task exports and run Windows Security → Virus & threat protection → Quick scan before removing evidence.
References