Ich kenne kein zentrales Fehlerverzeichnis. Man muss auch ein wenig zwischen Fehlermeldungen von Klassen, Paketen, LaTeX und TeX selbst unterscheiden. Die Fehlermeldungen von Klassen, Paketen und LaTeX sind meist recht zielführend. Bei einigen Paketen gibt es in der Anleitung auch eine Liste dieser Fehlermeldungen. der Fehlermeldungen, die von dem Paket ausgegeben werden können. In manchen Büchern, beispielsweise »[The LaTeX Companion](http://www.lehmanns.de/shop/mathematik-informatik/28107580-9780133387643-latex-companion)«, gibt es ebenfalls Verzeichnisse von Fehlern (im genannten Buch zu LaTeX-Fehlermeldungen). Die Fehlermeldungen von TeX sind ein anderes Kaliber. Diese sind nicht immer zielführend. Teilweise muss man schon ein gewisses Tiefenverständnis für die Arbeitsweise von TeX haben, um sie zu verstehen. Manchmal sind sie auch eher verwirrend. Die Meldung bezüglich `output dead cycles` besagt beispielsweise, dass die `output`-Routine von TeX mehr als `\maxdeadcycles` (Standardwert ist 100) aufgerufen wurde, ohne dass tatsächlich eine Ausgabe erfolgte. Man kann das einfach provozieren, indem man mehr als 100 `\clearpage` nacheinander aufruft. So etwas deutet meist darauf hin, dass irgend etwas im Dokument eine Ausgabeschleife auslöst, ohne dass Material produziert wird, etwa \@whilenum \value{page}<100\do {\clearpage} Hier fehlt zur reinen Demonstration schlicht in der geschweiften Klammer eine Ausgabe, wodurch zwar das erste `\clearpage` ggf. noch eine Seite ausgibt, dann aber keine Seite mehr ausgegeben wird, weil kein Material zur Ausgabe mehr vorhanden ist, wodurch auch `page` nicht mehr hochgezählt wird und so die Schleife auch nie abbricht (außer man war bereits auf einer Seite >= 100, als das Unglück geschah). Eine reine Erklärung zu diesem Fehler hilft Dir aber tatsächlich nicht weiter, weil es eigentlich nur die Erklärung zu einem Symptom wäre, die eigentliche Ursache dadurch aber leider nicht klar wird. Die Fehlermeldung bezüglich `undefined contol sequence` besagt eigentlich, dass ein Befehl (der, der in den angegebenen Code-Zeilen vor dem Umbruch steht) zwar verwendet wurde, aber nicht definiert ist. Im Fall von `\@nil` ist diese Fehlermeldung aber irreführend. `\@nil` ist eigentlich nie definiert und soll es auch nicht sein, sondern wird bei einigen internen Befehlen als Markierung für das Ende des Arguments verwendet. Wenn dieser Fehler auftritt, bedeutet das entweder, dass ein Befehl schlecht implementiert ist oder dass er nicht in vorgesehener Weise verwendet wird und daher etwas *zerbricht*. Auch hier handelt es sich also nur um die Fehlermeldung zu einem Symptom, aber nicht zur eigentlichen Ursache. In anderen Fällen stimmen Symptom und Ursache bei der »`undefined control sequence`«-Fehlermeldung aber mehr oder weniger überein, das heißt: Oftmals hat sich tatsächlich der Anwender selbst bei einem Befehl vertippt. Daher sollte bei diesem Fehler der Anwender immer genau hinschauen, welcher Befehl hier bemängelt wird. Wie gesagt: Wird `\@nil` angemahnt liegt die Ursache tiefer. Das trifft häufig auch zu, wenn ein anderer interner Befehl (zu erkennen am `@`) als nicht definiert gemeldet wird. Im Index kommt es zu solchen Fehlern nach meiner Erfahrung hauptsächlich, wenn zerbrechliche Befehle in den Index geschrieben werden. Siehe dazu: [Was sind zerbrechliche Befehle und bewegliche Argumente?](http://www.texwelt.de/wissen/fragen/68/was-sind-zerbrechliche-befehle-und-bewegliche-argumente). Auch bei der falschen Verwendung der Seitenzahlformatierung (meist durch `|` eingeleitet) kann so ein Fehler AFAIK auftreten. Wenn viele Fehler zu derselben Zeilennummer oder unmittelbar folgenden Zeilennummern angezeigt werden, handelt es sich dabei übrigens fast immer um *Folgefehler*. Das sind Fehler, die dadurch entstehen, dass TeX in einem Fehlerzustand weitermacht, als wäre nicht passiert. So würde etwa bei \begin{itmize} \item foo \end{itemize} nicht nur ein Fehler wegen des Tippfehlers in der ersten Zeile gemeldet. Auch die zweite Zeile wäre nun ein Fehler, weil `\item` nur in Listenumgebungen verwendet werden darf, aber eben wegen des Fehlers in der ersten Zeile keine solche geöffnet wurde. Selbst die letzte Zeile würde als Fehler gemeldet, weil das Ende der Umgebung nun nicht mehr zum falschen Anfang passt. Dennoch muss man hier nicht alle drei Fehler beheben, sondern nur den ersten. Die beiden anderen Fehler sind Folgefehler. Genaueres kann man ggf. nach Anfertigung eines [vollständigen Minimalbeispiels](http://texwelt.de/wissen/fragen/569/was-ist-ein-vollstandiges-minimalbeispiel-oder-kurz-vm-und-wie-erstelle-ich-dieses) ermitteln.

Ich kenne kein zentrales Fehlerverzeichnis. Man muss auch ein wenig zwischen Fehlermeldungen von Klassen, Paketen, LaTeX und TeX selbst unterscheiden. Die Fehlermeldungen von Klassen, Paketen und LaTeX sind meist recht zielführend. Bei einigen Paketen gibt es in der Anleitung auch eine Liste dieser Fehlermeldungen. Die Fehlermeldungen von TeX sind ein anderes Kaliber. Diese sind nicht immer zielführend. Teilweise muss man schon ein gewisses Tiefenverständnis für die Arbeitsweise von TeX haben, um sie zu verstehen. Manchmal sind sie auch eher verwirrend. Die Meldung bezüglich `output dead cycles` besagt beispielsweise, dass die `output`-Routine von TeX mehr als `\maxdeadcycles` (Standardwert ist 100) aufgerufen wurde, ohne dass tatsächlich eine Ausgabe erfolgte. Man kann das einfach provozieren, indem man mehr als 100 `\clearpage` nacheinander aufruft. So etwas deutet meist darauf hin, dass irgend etwas im Dokument eine Ausgabeschleife auslöst, ohne das dass Material produziert wird, etwa \@whilenum \value{page}<100\do {\clearpage} Hier fehlt zur reinen Demonstration schlicht in der geschweiften Klammer eine Ausgabe, wodurch zwar das erste `\clearpage` ggf. noch eine Seite ausgibt, dann aber keine Seite mehr ausgegeben wird, weil kein Material zur Ausgabe mehr vorhanden ist, wodurch auch `page` nicht mehr hochgezählt wird und so die Schleife auch nie abbricht (außer man war bereits auf einer Seite >= 100, als das Unglück geschah). Eine reine Erklärung zu diesem Fehler hilft Dir aber tatsächlich nicht weiter, weil es eigentlich nur die Erklärung zu einem Symptom wäre, die eigentliche Ursache dadurch aber leider nicht klar wird. Die Fehlermeldung bezüglich `undefined contol sequence` besagt eigentlich, dass ein Befehl (der, der in den angegebenen Code-Zeilen vor dem Umbruch steht) zwar verwendet wurde, aber nicht definiert ist. Im Fall von `\@nil` ist diese Fehlermeldung aber irreführend. `\@nil` ist eigentlich nie definiert und soll es auch nicht sein. Sondern sein, sondern wird bei einigen internen Befehlen als Markierung für das Ende des Arguments verwendet. Wenn dieser Fehler auftritt, bedeutet das entweder, dass ein Befehl schlecht implementiert ist, ist oder dass er nicht in vorgesehener Weise verwendet wird und daher etwas *zerbricht*. Auch hier handelt es sich also nur um die Fehlermeldung zu einem Symptom, aber nicht zur eigentlichen Ursache. In anderen Fällen stimmen Symptom und Ursache bei dieser Art Fehlermeldung der »`undefined control sequence`«-Fehlermeldung aber mehr oder weniger überein, das heißt: Oftmals hat sich tatsächlich der Anwender selbst bei einem Befehl vertippt. Daher sollte bei diesem Fehler der Anwender immer genau hinschauen, welcher Befehl hier bemängelt wird. Wie gesagt, wird gesagt: Wird `\@nil` angemahnt liegt die Ursache tiefer. tiefer. Das trifft häufig auch zu, wenn ein anderer interner Befehl (zu erkennen am `@`) als nicht definiert gemeldet wird. Im Index kommt es zu solchen Fehlern nach meiner Erfahrung hauptsächlich, wenn zerbrechliche Befehle in den Index geschrieben werden. Siehe dazu: [Was sind zerbrechliche Befehle und bewegliche Argumente?](http://www.texwelt.de/wissen/fragen/68/was-sind-zerbrechliche-befehle-und-bewegliche-argumente). Auch bei der falschen Verwendung der Seitenzahlformatierung (meist durch `|` eingeleitet) kann so ein Fehler AFAIK auftreten. Wenn viele Fehler zu derselben Zeilennummer oder unmittelbar folgenden Zeilennummers Zeilennummern angezeigt werden, handelt es sich dabei übrigens fast immer um Folgefehler. *Folgefehler*. Das sind Fehler, die dadurch entstehen, dass TeX in einem Fehlerzustand weitermacht, als wäre nicht passiert. So würde etwas etwa bei \begin{itmize} \item foo \end{itemize} nicht nur ein Fehler wegen des Tippfehlers in der ersten Zeile gemeldet. Auch die zweite Zeile wäre nun ein Fehler, weil `\item` nur in Listenumgebungen verwendet werden darf, aber eben wegen des Fehlers in der ersten Zeile keine solche geöffnet wurde. Selbst die letzte Zeile würde als Fehler gemeldet, weil das Ende der Umgebung nun nicht mehr zum falschen Anfang passt. Dennoch muss man hier nicht alle drei Fehler beheben, sondern nur den ersten. Die beiden anderen Fehler sind Folgefehler. Genaueres kann man ggf. nach Anfertigung eines [vollständigen Minimalbeispiels](http://texwelt.de/wissen/fragen/569/was-ist-ein-vollstandiges-minimalbeispiel-oder-kurz-vm-und-wie-erstelle-ich-dieses) ermitteln.

Ich kenne kein zentrales Fehlerverzeichnis. Man muss auch ein wenig zwischen Fehlermeldungen von Klassen, Paketen, LaTeX und TeX selbst unterscheiden. Die Fehlermeldungen von Klassen, Paketen und LaTeX sind meist recht zielführend. Bei einigen Paketen gibt es in der Anleitung auch eine Liste dieser Fehlermeldungen. Die Fehlermeldungen von TeX sind ein anderes Kaliber. Diese sind nicht immer zielführend. Teilweise muss man schon ein gewisses Tiefenverständnis für die Arbeitsweise von TeX haben, um sie zu verstehen. Manchmal sind sie auch eher verwirrend. Die Meldung bezüglich `output dead cycles` besagt beispielsweise, dass die `output`-Routine von TeX mehr als `\maxdeadcycles` (Standardwert ist 100) aufgerufen wurde, ohne dass tatsächlich eine Ausgabe erfolgte. Man kann das einfach provozieren, indem man mehr als 100 `\clearpage` nacheinander aufruft. So etwas deutet meist darauf hin, dass irgend etwas im Dokument eine Ausgabeschleife auslöst, ohne das Material produziert wird, etwa \@whilenum \value{page}<100\do {\clearpage} Hier fehlt zur reinen Demonstration schlicht in der geschweiften Klammer eine Ausgabe, wodurch zwar das erste `\clearpage` ggf. noch eine Seite ausgibt, dann aber keine Seite mehr ausgegeben wird, weil kein Material zur Ausgabe mehr vorhanden ist, wodurch auch `page` nicht mehr hochgezählt wird und so die Schleife auch nie abbricht (außer man war bereits auf einer Seite >= 100, als das Unglück geschah). geschah). Eine reine Erklärung zu diesem Fehler hilft Dir aber tatsächlich nicht weiter, weil es eigentlich nur die Erklärung zu einem Symptom wäre, die eigentliche Ursache dadurch aber leider nicht klar wird. Die Fehlermeldung bezüglich `undefined contol sequence` besagt eigentlich, dass ein Befehl (der, der in den angegebenen Code-Zeilen vor dem Umbruch steht) zwar verwendet wurde, aber nicht definiert ist. Im Fall von `\@nil` ist diese Fehlermeldung aber irreführend. `\@nil` ist eigentlich nie definiert und soll es auch nicht sein. Sondern wird bei einigen Befehlen als Markierung für das Ende des Arguments verwendet. Wenn dieser Fehler auftritt, bedeutet das entweder, dass ein Befehl schlecht implementiert ist, oder er nicht in vorgesehener Weise verwendet wird und daher etwas *zerbricht*. *zerbricht*. Auch hier handelt es sich also nur um die Fehlermeldung zu einem Symptom, aber nicht zur eigentlichen Ursache. In anderen Fällen stimmen Symptom und Ursache bei dieser Art Fehlermeldung aber mehr oder weniger überein, das heißt: Oftmals hat sich tatsächlich der Anwender selbst bei einem Befehl vertippt. Daher sollte bei diesem Fehler der Anwender immer genau hinschauen, welcher Befehl hier bemängelt wird. Wie gesagt, wird `\@nil` angemahnt liegt die Ursache tiefer. Im Index kommt es zu solchen Fehlern nach meiner Erfahrung hauptsächlich, wenn zerbrechliche Befehle in den Index geschrieben werden. Siehe dazu: [Was sind zerbrechliche Befehle und bewegliche Argumente?](http://www.texwelt.de/wissen/fragen/68/was-sind-zerbrechliche-befehle-und-bewegliche-argumente). Auch bei der falschen Verwendung der Seitenzahlformatierung (meist durch `|` eingeleitet) kann so ein Fehler AFAIK auftreten. Wenn viele Fehler zu derselben Zeilennummer oder unmittelbar folgenden Zeilennummers angezeigt werden, handelt es sich dabei übrigens fast immer um Folgefehler. Das sind Fehler, die dadurch entstehen, dass TeX in einem Fehlerzustand weitermacht, als wäre nicht passiert. So würde etwas bei \begin{itmize} \item foo \end{itemize} nicht nur ein Fehler wegen des Tippfehlers in der ersten Zeile gemeldet. Auch die zweite Zeile wäre nun ein Fehler, weil `\item` nur in Listenumgebungen verwendet werden darf, aber eben wegen des Fehlers in der ersten Zeile keine solche geöffnet wurde. Selbst die letzte Zeile würde als Fehler gemeldet, weil das Ende der Umgebung nun nicht mehr zum falschen Anfang passt. Dennoch muss man hier nicht alle drei Fehler beheben, sondern nur den ersten. Die beiden anderen Fehler sind Folgefehler. Genaueres kann man ggf. nach Anfertigung eines [vollständigen Minimalbeispiels](http://texwelt.de/wissen/fragen/569/was-ist-ein-vollstandiges-minimalbeispiel-oder-kurz-vm-und-wie-erstelle-ich-dieses) ermitteln.

Ich kenne kein zentrales Fehlerverzeichnis. Man muss auch ein wenig zwischen Fehlermeldungen von Klassen, Paketen, LaTeX und TeX selbst unterscheiden. Die Fehlermeldungen von Klassen, Paketen und LaTeX sind meist recht zielführend. Bei einigen Paketen gibt es in der Anleitung auch eine Liste dieser Fehlermeldungen. Die Fehlermeldungen von TeX sind ein anderes Kaliber. Diese sind nicht immer zielführend. Teilweise muss man schon ein gewisses Tiefenverständnis für die Arbeitsweise von TeX haben, um sie zu verstehen. Manchmal sind sie auch eher verwirrend. Die Meldung bezüglich `output dead cycles` besagt beispielsweise, dass die `output`-Routine von TeX mehr als `\maxdeadcycles` (Standardwert ist 100) aufgerufen wurde, ohne dass tatsächlich eine Ausgabe erfolgte. Man kann das einfach provozieren, indem man mehr als 100 `\clearpage` nacheinander aufruft. So etwas deutet meist darauf hin, dass irgend etwas im Dokument eine Ausgabeschleife auslöst, ohne das Material produziert wird, etwa \@whilenum \value{page}<100\do {\clearpage} Hier fehlt zur reinen Demonstration schlicht in der geschweiften Klammer eine Ausgabe, wodurch zwar das erste `\clearpage` ggf. noch eine Seite ausgibt, dann aber keine Seite mehr ausgegeben wird, weil kein Material zur Ausgabe mehr vorhanden ist, wodurch auch `page` nicht mehr hochgezählt wird und so die Schleife auch nie abbricht (außer man war bereits auf einer Seite >= 100, als das Unglück geschah). Die Fehlermeldung bezüglich `undefined contol sequence` besagt eigentlich, dass ein Befehl (der, der in den angegebenen Code-Zeilen vor dem Umbruch steht) zwar verwendet wurde, aber nicht definiert ist. Im Fall von `\@nil` ist diese Fehlermeldung aber irreführend. `\@nil` ist eigentlich nie definiert und soll es auch nicht sein. Sondern wird bei einigen Befehlen als Markierung für das Ende des Arguments verwendet. Wenn dieser Fehler auftritt, bedeutet das entweder, dass ein Befehl schlecht implementiert ist, oder er nicht in vorgesehener Weise verwendet wird und daher etwas *zerbricht*. Im Index kommt es zu solchen Fehlern nach meiner Erfahrung hauptsächlich, wenn zerbrechliche Befehle in den Index geschrieben werden. Siehe dazu: [Was sind zerbrechliche Befehle und bewegliche Argumente?](http://www.texwelt.de/wissen/fragen/68/was-sind-zerbrechliche-befehle-und-bewegliche-argumente). Auch bei der falschen Verwendung der Seitenzahlformatierung (meist durch `|` eingeleitet) kann so ein Fehler AFAIK auftreten. Wenn viele Fehler zu derselben Zeilennummer oder unmittelbar folgenden Zeilennummers angezeigt werden, handelt es sich dabei übrigens fast immer um Folgefehler. Das sind Fehler, die dadurch entstehen, dass TeX in einem Fehlerzustand weitermacht, als wäre nicht passiert. So würde etwas bei \begin{itmize} \item foo \end{itemize} nicht nur ein Fehler wegen des Tippfehlers in der ersten Zeile gemeldet. Auch die zweite Zeile wäre nun ein Fehler, weil `\item` nur in Listenumgebungen verwendet werden darf, aber eben wegen des Fehlers in der ersten Zeile keine solche geöffnet wurde. Selbst die letzte Zeile würde als Fehler gemeldet, weil das Ende der Umgebung nun nicht mehr zum falschen Anfang passt. Dennoch muss man hier nicht alle drei Fehler beheben, sondern nur den ersten. Die beiden anderen Fehler sind Folgefehler. Genaueres kann man ggf. nach Anfertigung eines [vollständigen Minimalbeispiels](http://texwelt.de/wissen/fragen/569/was-ist-ein-vollstandiges-minimalbeispiel-oder-kurz-vm-und-wie-erstelle-ich-dieses) ermitteln.

Ich kenne kein zentrales Fehlerverzeichnis. Man muss auch ein wenig zwischen Fehlermeldungen von Klassen, Paketen, LaTeX und TeX selbst unterscheiden. Die Fehlermeldungen von Klassen, Paketen und LaTeX sind meist recht zielführend. Bei einigen Paketen gibt es in der Anleitung auch eine Liste dieser Fehlermeldungen. Die Fehlermeldungen von TeX sind ein anderes Kaliber. Diese sind nicht immer zielführend. Teilweise muss man schon ein gewisses Tiefenverständnis für die Arbeitsweise von TeX haben, um sie zu verstehen. Manchmal sind sie auch eher verwirrend. Die Meldung bezüglich `output dead cycles` besagt beispielsweise, dass die `output`-Routine von TeX mehr als `\maxdeadcycles` (Standardwert ist 100) aufgerufen wurde, ohne dass tatsächlich eine Ausgabe erfolgte. Man kann das einfach provozieren, indem man mehr als 100 `\clearpage` nacheinander aufruft. So etwas deutet meist darauf hin, dass irgend etwas im Dokument eine Ausgabeschleife auslöst, ohne das Material produziert wird, etwa \@whilenum \value{page}<100\do {\clearpage} Hier fehlt zur reinen Demonstration schlicht in der geschweiften Klammer eine Ausgabe, wodurch zwar das erste `\clearpage` ggf. noch eine Seite ausgibt, dann aber keine Seite mehr ausgegeben wird, weil kein Material zur Ausgabe mehr vorhanden ist, wodurch auch `page` nicht mehr hochgezählt wird und dadurch auch `page` nicht mehr hochgezählt wird. so die Schleife auch nie abbricht (außer man war bereits auf einer Seite >= 100, als das Unglück geschah). Die Fehlermeldung bezüglich `undefined contol sequence` besagt eigentlich, dass ein Befehl (der, der in den angegebenen Code-Zeilen vor dem Umbruch steht) zwar verwendet wurde, aber nicht definiert ist. Im Fall von `\@nil` ist diese Fehlermeldung aber irreführend. `\@nil` ist eigentlich nie definiert und soll es auch nicht sein. Sondern wird bei einigen Befehlen als Markierung für das Ende des Arguments verwendet. Wenn dieser Fehler auftritt, bedeutet das entweder, dass ein Befehl schlecht implementiert ist, oder er nicht in vorgesehener Weise verwendet wird und daher etwas *zerbricht*. Im Index kommt es zu solchen Fehlern nach meiner Erfahrung hauptsächlich, wenn zerbrechliche Befehle in den Index geschrieben werden. Siehe dazu: [Was sind zerbrechliche Befehle und bewegliche Argumente?](http://www.texwelt.de/wissen/fragen/68/was-sind-zerbrechliche-befehle-und-bewegliche-argumente). Auch bei der falschen Verwendung der Seitenzahlformatierung (meist durch `|` eingeleitet) kann so ein Fehler AFAIK auftreten. Genaueres kann man ggf. nach Anfertigung eines [vollständigen Minimalbeispiels](http://texwelt.de/wissen/fragen/569/was-ist-ein-vollstandiges-minimalbeispiel-oder-kurz-vm-und-wie-erstelle-ich-dieses) ermitteln.

Ich kenne kein zentrales Fehlerverzeichnis. Man muss auch ein wenig zwischen Fehlermeldungen von Klassen, Paketen, LaTeX und TeX selbst unterscheiden. Die Fehlermeldungen von Klassen, Paketen und LaTeX sind meist recht zielführend. Bei einigen Paketen gibt es in der Anleitung auch eine Liste dieser Fehlermeldungen. Die Fehlermeldungen von TeX sind ein anderes Kaliber. Diese sind nicht immer zielführend. Teilweise muss man schon ein gewisses Tiefenverständnis für die Arbeitsweise von TeX haben, um sie zu verstehen. Manchmal sind sie auch eher verwirrend. Die Meldung bezüglich `output dead cycles` besagt beispielsweise, dass die `output`-Routine von TeX mehr als `\maxdeadcycles` (Standardwert ist 100) aufgerufen wurde, ohne dass tatsächlich eine Ausgabe erfolgte. Man kann das einfach provozieren, indem man mehr als 100 `\clearpage` nacheinander aufruft. So etwas deutet meist darauf hin, dass irgend etwas im Dokument eine Ausgabeschleife auslöst, ohne das Material produziert wird, etwa \@whilenum \value{page}<100\do {\clearpage} Hier fehlt schlicht in der geschweiften Klammer eine Ausgabe, wodurch zwar das erste `\clearpage` ggf. noch eine Seite ausgibt, dann aber keine Seite mehr ausgegeben wird und dadurch auch `page` nicht mehr hochgezählt wird. Die Fehlermeldung bezüglich `undefined contol sequence` besagt eigentlich, dass ein Befehl (der, der in den angegebenen Code-Zeilen vor dem Umbruch steht) zwar verwendet wurde, aber nicht definiert ist. Im Fall von `\@nil` ist diese Fehlermeldung aber irreführend. `\@nil` ist eigentlich nie definiert und soll es auch nicht sein. Sondern wird bei einigen Befehlen als Markierung für das Ende des Arguments verwendet. Wenn dieser Fehler auftritt, bedeutet das entweder, dass ein Befehl schlecht implementiert ist, oder er nicht in vorgesehener Weise verwendet wird und daher etwas *zerbricht*. Im Index kommt es zu solchen Fehlern nach meiner Erfahrung hauptsächlich, wenn zerbrechliche Befehle in den Index geschrieben werden. Siehe dazu: [Was sind zerbrechliche Befehle und bewegliche Argumente?](http://www.texwelt.de/wissen/fragen/68/was-sind-zerbrechliche-befehle-und-bewegliche-argumente). Auch bei der falschen Verwendung der Seitenzahlformatierung (meist durch `|` eingeleitet) kann so ein Fehler AFAIK auftreten. Genaueres kann man ggf. nach Anfertigung eines [vollständigen Minimalbeispiels](http://texwelt.de/wissen/fragen/569/was-ist-ein-vollstandiges-minimalbeispiel-oder-kurz-vm-und-wie-erstelle-ich-dieses) ermitteln.