diff --git a/docs/guides/component-testing/third-party-definitions.mdx b/docs/guides/component-testing/third-party-definitions.mdx
index bf653c0fa4..b058a79767 100644
--- a/docs/guides/component-testing/third-party-definitions.mdx
+++ b/docs/guides/component-testing/third-party-definitions.mdx
@@ -63,7 +63,7 @@ When configuring a project to use Component Testing, Cypress will load any
dependencies following this naming convention from the project's `node_modules`
and present them as framework options.
-A simple example of a Framework Defintion for the
+A simple example of a Framework Definition for the
[Solid.js](https://www.solidjs.com/) library is shown below. We generally
recommend naming this `definition.cjs`. In our
[official template](https://github.com/cypress-io/cypress-ct-definition-template),
@@ -167,7 +167,8 @@ indicating it's a third party definition.
We defined the `dependencies`, which are also correctly handled - we haven't
@@ -175,9 +176,29 @@ installed them all, so Cypress is prompting us to do so:
+From Cypress version 12.10.0, if there is a problem loading or
+parsing a framework definition, Cypress will display a warning:
+
+
+
+To see more detailed error information, use the
+`scaffold-config:ct-detect-third-party` namespace for
+[logging](/guides/references/troubleshooting#Print-DEBUG-logs), like this:
+
+```bash
+DEBUG=cypress:scaffold-config:ct-detect-third-party npx cypress open
+```
+
## Mount Adapter
The second part of defining a Framework Definition is the Mount Adapter. This is
diff --git a/static/img/guides/component-testing/framework-definition-errors.png b/static/img/guides/component-testing/framework-definition-errors.png
new file mode 100644
index 0000000000..93fb6d1db8
Binary files /dev/null and b/static/img/guides/component-testing/framework-definition-errors.png differ