When you distribute your game and patch system, there’s nothing worse than being blind to any issues.
We solve this in two ways for you.
The first is, every time someone connects to your patch system to use it, there are ‘skim logs’ provided to the server. You can view these logs inside your dashboard. These are just general messages, however you can look out for errors in there too.
The second method is debug logging. Debug logging can be enabled by default by supplying the -verbose command line parameter. However, with LaunchBoost.io, you don’t need to specify -verbose every time. By forcing the patch system to debug log every time it is run, means you will be causing unnecessary slow-downs for your users as to the patch system writes to the hard drive throughout the whole process.
This slows down the hard drive’s I/O speeds by accumulating in the buffer and it can also slow down the process threads in the CPU.
To counter this, you can just run your patch system without the -verbose command line parameter and if the patch system crashes or fails, it will auto-detect this, so the next time your game, or your user tries to update again, it will prompt the user if they want to enable debug logging.
Debug Logging
The message sent to your dashboard online are generic messages like “User Connected”, “User Finished Patching Successfully”, “Patching Failed” etc. but provide no real insights as to why.
This is where debug logging comes in handy. When a user or a game runs the patch system and debug logging is enabled, it will write everything to a specific log file on the user’s computer. So should it crash or fail whilst debug logging is enabled, this crash or fail will be logged.
In this instance, you should ask your user to send you the debug log file so you can take a look inside and inspect what happened to make it crash or fail.
Your user can find the debug log files at:
There should be at least two files in there. One is called lastpatchlog.html and the other will be debuglog-<timestamp>.txt.
Ideally, you want them to send you lastpatchlog.html as this gives the full overview of what happened in the last patch attempt they tried.
The debug log is super-easy to read through. You should double-check ALL the details like URLs from the file. Copy the URLs to your browser and go to the URL and see if it works.
If it doesn’t, it’s a web host error or you have misconfigured a URL somewhere so then you need to check your Patch Settings.
For all other errors, please see this documentation section “debug log errors”.
Common Issues
1. “Write Access Denied”
Cause: The game is installed in
C:\Program Filesor another protected folder/drive and the user is not Admin.Behavior: The patcher will attempt to auto-elevate using UAC (User Account Control). If the user says “No”, patching aborts.
2. “Integrity Violation”
Cause: The
patcher.exebinary has been modified or corrupted.Behavior: The app exits immediately.
3. “Safe Mode” Prompt
Cause: The patcher crashed or was force-closed during the previous run.
Behavior: The user is asked if they want to enable Debug Logging for this run.