LAMA0001: Metalama failed with an unexpected exception

Cause

Metalama reports LAMA0001 when an exception that it didn't anticipate escapes from its compile-time pipeline. This is a bug in Metalama, not in your code, even if a particular construct in your code triggers it.

In the message, <Message> is the message of the exception, and <File> is the path of the crash report that Metalama wrote. The crash report is a text file that contains the version of Metalama, the .NET runtime and operating system, the exception type, message and stack trace, and, when the exception relates to a specific syntax tree, the full text of this source file.

Exceptions thrown by your own compile-time code, for instance by the BuildAspect method of an aspect or by a template, aren't reported as LAMA0001 but as LAMA0041. Exceptions that Metalama can ignore, typically during design-time code generation in the IDE, are reported as the warning LAMA0049.

This diagnostic is caused by a defect in Metalama, so it can't be shown in an example.

Resolution

1. Open the crash report file given in the message. By default, crash reports are written to the following directory and deleted one month after their creation:

   • On Windows: %TEMP%\Metalama\CrashReports.
   • On Linux and macOS: the Temp/CrashReports subdirectory of the Metalama application data directory, for instance ~/.local/share/Metalama/Temp/CrashReports on Linux.

   If you set the METALAMA_TEMP environment variable, the reports are in $METALAMA_TEMP/Metalama/CrashReports. If the message gives <error> instead of a path, Metalama couldn't write the file, and it reports the warning LAMA0076 with the reason.

2. Check whether the problem is already fixed: update the Metalama packages to the latest version of your release line and rebuild. Also check the existing issues.

3. Report the problem, as described in How to file an issue, and attach the crash report. Before you send it, review the file and remove anything confidential: it may contain fragments or whole files of your source code. If you can, add a minimal project that reproduces the exception.

4. Until the bug is fixed, try to find the construct that triggers the exception, using the stack trace and the source file included in the report, and rewrite it in another way. A clean rebuild (deleting the obj and bin directories) or restarting the compiler server with metalama kill sometimes resolves exceptions caused by a stale cache.

See also

• How to file an issue
• Enabling logging
• Creating a process dump