AssetRipper stuck on no files loaded
No files loaded usually means the selected path did not expose supported Unity data to the importer. It does not automatically mean that AssetRipper is broken. Check the folder level first: a parent directory may contain screenshots, launchers, or platform folders while the serialized files sit deeper inside. Then try one smaller file or bundle that you know should be relevant.
If the path is correct, confirm that the archive was extracted completely and that the files are not encrypted, compressed in an unsupported way, or part of a custom container. Record the file extension, Unity version clue, AssetRipper version, and any console warning before changing the input.
The scan completes immediately
Likely cause: The selected folder may not contain recognized Unity serialized files.
Try this: Move one level deeper, try a known asset file, and compare the folder contents with the expected Unity build layout.
The scan never finds the expected bundle
Likely cause: The file may be encrypted, custom-packed, or still inside another archive.
Try this: Confirm the input is extracted and authorized, then test a standard serialized file or a documented bundle.
Error while reading an assets file
An error while reading an assets file can be caused by a truncated download, an incomplete copy, an unsupported Unity type, a wrong file selected as an assets file, or a dependency that is not available. Re-copy the source from a trusted location, compare file sizes, and test the newest stable AssetRipper build before trying a development build.
Do not repeatedly overwrite the same output while investigating. Keep the original file, a copy of the error message, and a small test directory so you can tell whether the error follows the input or the destination.
- Check that the file was copied completely and is not zero bytes or unexpectedly small.
- Check that you are loading Unity data rather than a launcher, patch file, archive index, or unrelated DLL.
- Check the AssetRipper release notes and issue tracker for the exact parser or Unity version clue.
- Test a second file from the same source to see whether the problem is isolated or systemic.
AssetRipper crashes while exporting or reports a memory limit
Large exports can consume more memory than the source size suggests because textures may be decoded, meshes converted, and project files generated at the same time. Reduce the scope and export one content group before attempting a complete project. Close other memory-heavy tools, use a local SSD path with free space, and avoid running from a network or synchronized folder during the test.
If a small export succeeds but a large export crashes, the result is useful evidence: the parser may be fine and the job may simply be too broad for the available resources. If even a small known input crashes, capture the version, platform, file type, and stack or log output and report it to the official project.
Crash happens near the end of a large export
Likely cause: Peak memory or temporary disk use may exceed available resources.
Try this: Export fewer assets, split the input, increase free space, and close other large applications.
Crash happens on every input
Likely cause: The build, native dependency, permission, or input format may be invalid.
Try this: Re-extract the official stable build and test a small known-good file in a writable folder.
Empty GLB files, missing textures, or shader problems
An empty GLB is often a dependency or selection problem rather than a simple button failure. The selected object may reference a mesh stored in another file, the mesh may not be supported, or the export may have produced a file while omitting resources the viewer cannot resolve. Check the output directory, inspect any companion textures, and test a different recognized model before drawing a conclusion.
Shader problems are common in reconstructed projects because custom or stripped shaders may not map cleanly to a normal Unity editor project. Preserve the geometry and texture results even when the original material appearance is not available, then decide whether manual shader replacement is appropriate for your authorized use.
AssetRipper Troubleshooting: use a controlled test
Good AssetRipper Troubleshooting changes one variable at a time. Start by copying the smallest authorized input that still reproduces the problem. Note the operating system, AssetRipper version, Unity version clue, file extension, folder level, export mode, and exact message. This short record prevents a common mistake: changing the build, the input, the destination, and the viewer together, then not knowing which change mattered.
Use a clean output folder for every comparison and keep the source untouched. If the issue is no files loaded, compare the selected folder with the files that actually contain Unity data. If the issue is an assets-file read error, compare the file size and test another file from the same source. If the issue is an export crash, reduce the input until the operation completes, then add content in small groups until the boundary is visible.
Warnings are evidence, not automatically a failure verdict. A project can export with a missing shader, a texture can load while a material does not, and a model can contain geometry without its external resources. Separate parser behavior from viewer behavior by opening the result in an appropriate target tool. When reporting a bug, include the smallest reproduction you are allowed to share and explain what you expected versus what you observed.
AssetRipper troubleshooting is more efficient when the symptom is narrowed before the tool version changes. Capture the exact message, file path, operating system, release version, and selected folder. Then repeat the smallest possible test with one known input. This separates no files loaded, a parser warning, a missing dependency, a memory limit, and a viewer problem instead of treating every incomplete result as the same failure.
Keep a small reproduction folder for every difficult AssetRipper error. Include only the authorized files needed to reproduce the symptom and save the output and log beside your notes. If the small test succeeds, add one dependency or one content type at a time. If it fails consistently, the reduced example is easier to compare across builds and much more useful in an official GitHub issue than a large folder with unknown changes.
- Reproduce the symptom with a stable official build before comparing a pre-release or development build.
- Use a local writable path with free disk space and close other memory-heavy applications during export tests.
- Keep logs, screenshots, filenames, and warning text together so another person can repeat the same test.
- Stop when the input is protected or unauthorized; troubleshooting should not become an attempt to bypass encryption, DRM, or access controls.
AssetRipper Troubleshooting questions
Why is AssetRipper stuck on no files loaded?
The path may be the wrong folder level, the data may not be supported Unity content, or the files may be encrypted or custom-packed. Start with one known input and verify the extracted layout.
What should I do when AssetRipper crashes while exporting?
Reduce the export scope, use a writable local folder, close memory-heavy applications, check free disk space, and test the stable release with a small input.
Why are my GLB files empty?
The selected object may not include mesh data, dependencies may be missing, the model type may be unsupported, or your viewer may not resolve external resources.
Where should I report an AssetRipper bug?
Use the official AssetRipper GitHub repository and include the version, operating system, input type, exact error, and a minimal authorized reproduction when possible.