I'm experiencing a reproducible startup crash with RAGE Plugin Hook version 1.131.1424.17745 on GTA V Legacy.

RPH crashes before the launcher/UI opens.

Windows Event Viewer reports:

Application: RAGEPluginHook.exe
Framework Version: v4.0.30319

Exception Info: System.ArgumentException
   at System.IO.Path.CheckInvalidPathChars(System.String, Boolean)
   at System.IO.Path.GetExtension(System.String)
   at [RPH startup method]
   at System.Windows.Application.OnStartup(System.Windows.StartupEventArgs)

The WER event reports:

Event Name: CLR20r3
P1: RAGEPluginHook.exe
P2: 1.131.1424.17745
P4: mscorlib
P9: System.ArgumentException

I performed DISM and SFC repairs successfully and rebooted, but the crash remained unchanged.

While investigating the startup crash, I found that RPH references:

http://ragepluginhook.net/LatestVersion.aspx

That URL currently returns an ASP.NET HTTP 404 error page:

Server Error in '/' Application.

The resource cannot be found.

Requested URL: /LatestVersion.aspx

The important reproduction result is:

Internet connected: RAGEPluginHook.exe crashes immediately.

Internet completely disconnected: RAGEPluginHook.exe opens successfully.

I then created an outbound Windows Firewall rule blocking only RAGEPluginHook.exe.

With normal internet access restored, but outbound access blocked specifically for RAGEPluginHook.exe, RPH opens successfully again.

The firewall rule used was:

netsh advfirewall firewall add rule name="Block RAGEPluginHook Outbound" dir=out action=block program="D:\SteamLibrary\steamapps\common\Grand Theft Auto V Legacy\RAGEPluginHook.exe" enable=yes

This appears to indicate that a network request performed during RPH startup is triggering the crash. Given the Path.GetExtension() / CheckInvalidPathChars() exception and the current HTML 404 response from LatestVersion.aspx, it may be worth checking whether the startup/version-check code is receiving an unexpected HTML response and subsequently attempting to process it as a path or filename.

I also captured full Windows crash dumps if they would be useful for debugging.

Thanks for the report - it sounds like you've found a solid workaround.

I've looked into this a bit further. A 404 page wouldn't produce this error (and observably so, as nobody would be playing LSPDFR right now!).

However, an invalid response which returns 200 (e.g. network level interception on the local machine/network, or abnormal cloudflare challenge) could. I'll look into a fix for a future release.