-
Notifications
You must be signed in to change notification settings - Fork 16
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
feat: procmon library to monitor system calls #281
Open
icex2
wants to merge
22
commits into
djhackersdev:development
Choose a base branch
from
icex2:procmon-launcher
base: development
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We want this to always be visible, so the log level must be the highest possible. Unfortunately, that's quite the hack around the existing API and how fatal behaves. The log API stopped scaling already a while ago and needs considerable refactoring to consider the various use-cases that emerged since it was first created on alpha versions of bemanitools.
Because we are using mingw, we can't just use window's dbghelp library as the symbols created are in dwarf format. Fortunately, the dwarfstack library already provides all the facilities to easily print very descriptive stacktraces, including function names, file names and line numbers, when dwarf symbols are available. This moves the incomplete exception handling portion from signal to a separate module as well to improve scoping.
Adjust inject to utilize the new feature. This also requires including the dwarfstack.dll in all distribution packages.
Expecting to improve debugability significantly. Stacktraces can be enhanced with function names, file names and line numbers when symbols are included in all exe and dll files. Furthermore, this also improves debugger usage as symbols can be imported to help navigate disassembly/decompiled code.
This has been a source of common error in the past. It is known that most, or even all, games run into various issues when not run with elevated privileges.
Use this to share helpers or other extensions to the original avs API across modules. Start with including error codes to readable strings to improve velocity on AVS API error analysis.
Taken from a private eamuse server backend which had more complete mappings.
Supports improving expressiveness of the API interface
These were previously missing and are required for various file system related tasks such as iterating directory trees, reading and writing files through the AVS file system for the upcoming launcher rework. Note that the AVS API broke with some mode flags after version 2.13.06.
Again, required for the launcher rework when dealing with property node trees.
Add all functions and their respective ordinals (and mangled names for documentation purpose) to all currently used AVS version.
This one was missing and is the actual correct version used for ddr-13. 2.13.04 was compatible, thus far, but there isn't any guarantee that they are actually 100% compatible (only konmai knows...).
Apparently forgotten to get updated to reflect the currently supported versions correctly.
Apparently also forgotten to reflect currently supported games.
Kudos to Shiz for providing the groundwork for this. Fundamentally re-think how launcher operates and bootstrapping the games is managed and configured. This brings it significantly closer to how the original bootstrap is doing the job: launcher now utilizes the data (structures) provided by the bootstrap.xml configuration file. This creates compatibility with vanilla data dumps and original stock images. Note that bemanitools does not include any code or means to run DRM'd data, only decrypted. But, this allows users to keep decrypted dumps as stock as possible which means: * No copying around of property files anymore * Keep the modules/ folder with the binaries * Have bemanitools binaries separate in the data * No need to edit/customize the original configuration files A list of key features of the "new" launcher: * Boostrap games by following the configuration provided by stock game's bootstrap.xml files * Custom launcher.xml configuration file that adds further launcher configurable features, composability of bootstrap.xml configuration(s) as well as configuration overriding/stacking of selected types of configurations, e.g. eamuse config, avs-config. The latter eliminates the need for modifying stock config files in the prop/ folder * Unified logging system: launcher and AVS logging uses the same logger, all output can now be in a single file * Original features such as various hook types still available Due to the significant architectural changes, this also breaks with any backwards compatibility to existing launcher setups. Thus, users need to migrate by re-applying the new configuration format and migrating their config parameters accordingly. Further migration instructions and updated documentation will be provided upon release. Co-authored-by: Shiz <[email protected]>
Move everything to new launcher.xml configuration files. Adjust the bootstrapping of launcher in the .bat files. Features such as copying the default props/ files to nvram are now handled by launcher. Using the PATH variable, bemanitools binaries can live in their own dedicated bemanitools/ subfolder next to props/ and modules/ now. All original binaries are expected to be kept in a modules/ folder like on stock data.
A general debugging tool. 3rd party applications such as "procmon" (same name) provide these capabilites and even more. But, they are more difficult to run with bemanitools and don't provide a unified look at the output in combination with the log output by bemanitools. Provide an initial set of system call hooks that have already supported debugging efforts. More can be added when needed later.
Integrate this as an optional dependency into launcher and load it dynamically. Thus, these can be easily loaded/enabled by developers and end-users.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A general debugging tool. 3rd party applications such as
"procmon" (same name) provide these capabilites and even
more. But, they are more difficult to run with bemanitools
and don't provide a unified look at the output in combination
with the log output by bemanitools.
Provide an initial set of system call hooks that have already
supported debugging efforts. More can be added when needed
later.
Integrate this as an optional dependency into launcher and
load it dynamically. Thus, these can be easily loaded/enabled
by developers and end-users.