Anzeige
Anzeige

Am Puls von Microsoft

Anzeige

Bekomme unterschiedliche Bluescreens angezeigt

Diese sitzt unter der Grafikkarte!

Gucke am unteren Bereich des Mainboards nach einen Low-Pin Count-Header mit drei Pins und mit aufgesetztem Jumper - dies ist der CMOS Clear Jumper!
Diesen von links nach rechts auf den ungenutzten Pin umstecken, oder umgekehrt!
 
Anzeige
so habe nun die cmos batterie wieder drin und komme ins uefi, wo finde ich das ram cmp profil und ist das was du meinst mit cas latency auf 16 zu stellen?
 
Was ist eigentlich vorgefallen? Von nichts kommt nichts.


- Knotenpunkt "Hauptmenü"; Uhrzeit und Datum einstellen
- Knotenpunkt "Motherboard Settings"; Rubrik "Hardware": Lüfter einstellen (alterativ)
- Knotenpunkt "Motherboard Settings"; Rubrik "Boot": AHCI-Modus aktivieren (wenn nicht die Voreinstellung)
- Knotenpunkt "Motherboard Settings"; Rubrik "Boot": UEFI-Modus aktivieren (nur bei EFI)
- Knotenpunkt "Motherboard Settings"; Rubrik "Boot": Secure Boot laden und aktivieren (nur bei EFI)
- Knotenpunkt "OC"; Rubrik "Memory Management": XMP-Profil laden

RAM- und OC-Geschichten folgen immer an letzter Stelle und diese nicht sogleich - immer Neustarts dazwischen bringen!

Richtig - CAS Latency (tCL). ^^
 
Habe alles eingestellt, das meiste war schon eingestellt.
cas latency war schon standartmäßig auf 16 eingestellt.

Was ist nun mit dem DUmp Dateien die ich angeheftet habe? was kann man aus ihnen schließen?
 
Danke!

Die Einstellung von zuvor ist "15" gewesen.


Die Auswertung der Dumpfiles übernimmt Ari45 - da funke ich ihm nicht dazwischen. ^^
 
Ich will Dich nicht ewig in Ungewissheit zappeln lassen und zu tun habe ich derzeit sowieso nichts Wichtiges - außer mich mit einer Erkältung herumzuplagen.

Ich halte 's kurz und knapp und hoffe, dass Ari45 es mir nicht verübelt!


Der Speicherfehler ist aus allen 5 Dumpfles abzuleiten, doch ersichtlich ist er einzig in diesen beiden Dumpfiles.
Das erkennbare Muster aller Dumpfiles ist: BUCKET_ID: WRONG_SYMBOLS
- Datenintegritätsfehler

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: fffff8047670049c, memory referenced.
Arg2: 0000000000000010, value 0 = read operation, 1 = write operation.
Arg3: fffff8047670049c, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000002, (reserved)

Debugging Details:
------------------


WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPagedPoolEnd
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSizeOfNonPagedPoolInBytes
fffff8047670049c

FAULTING_IP:
+0
fffff804`7670049c ?? ???

MM_INTERNAL_CODE: 2

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: AV

PROCESS_NAME: System

CURRENT_IRQL: 0

TRAP_FRAME: ffff9080fa9f9fb0 -- (.trap 0xffff9080fa9f9fb0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff804f7c4c6b8 rbx=0000000000000000 rcx=ffffb70b37b4e230
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8047670049c rsp=ffff9080fa9fa148 rbp=ffff9080fa9fa250
r8=0000000000000000 r9=0000000000000003 r10=0000000000000000
r11=fffff804f7c2d84b r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
fffff804`7670049c ?? ???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff8028ca066ca to fffff8028c9d12b0

STACK_TEXT:
ffff9080`fa9f9cb8 fffff802`8ca066ca : 00000000`00000050 fffff804`7670049c 00000000`00000010 ffff9080`fa9f9fb0 : nt!KeBugCheckEx
ffff9080`fa9f9cc0 fffff802`8c8f7ffa : 00000000`00000010 00000000`00000000 ffff9080`fa9f9fb0 ffff9080`fa9f9eb9 : nt! ?? ::FNODOBFM::`string'+0x2623a
ffff9080`fa9f9db0 fffff802`8c9da8fc : ffff9080`fa9f9f68 00000000`00000008 ffff9080`fa9f9f80 00000000`00000008 : nt!MmAccessFault+0x9ca
ffff9080`fa9f9fb0 fffff804`7670049c : fffff804`f774a30b 00000000`00000000 ffff9080`fa9fa250 00000000`00000000 : nt!KiPageFault+0x13c
ffff9080`fa9fa148 fffff804`f774a30b : 00000000`00000000 ffff9080`fa9fa250 00000000`00000000 00000000`00008000 : 0xfffff804`7670049c
ffff9080`fa9fa150 00000000`00000000 : ffff9080`fa9fa250 00000000`00000000 00000000`00008000 ffffb70b`285a45f0 : nvlddmkm+0x10a30b


STACK_COMMAND: kb

FOLLOWUP_IP:
nvlddmkm+10a30b
fffff804`f774a30b 898500030000 mov dword ptr [rbp+300h],eax

SYMBOL_STACK_INDEX: 5

SYMBOL_NAME: nvlddmkm+10a30b

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nvlddmkm

IMAGE_NAME: nvlddmkm.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 588210d7

FAILURE_BUCKET_ID: X64_AV_nvlddmkm+10a30b

BUCKET_ID: X64_AV_nvlddmkm+10a30b

Followup: MachineOwner


In diesem gesonderten Fall ist dasjenige eingetreten, was ich erhofft hatte, zu sehen zu bekommen - der Fehler am Energiezustand: Der Speicherfehler während der Transaktion.

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: fffff8020e2f58b0, memory referenced.
Arg2: 0000000000000010, value 0 = read operation, 1 = write operation.
Arg3: fffff8020e2f58b0, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000002, (reserved)

Debugging Details:
------------------


MODULE_NAME: ACPI

FAULTING_MODULE: fffff8021e289000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 578997a7

WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPagedPoolEnd
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSizeOfNonPagedPoolInBytes
fffff8020e2f58b0

FAULTING_IP:
+0
fffff802`0e2f58b0 ?? ???

MM_INTERNAL_CODE: 2

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: AV

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff8021e424b54 to fffff8021e3d36f0

STACK_TEXT:
ffff9b80`1006c028 fffff802`1e424b54 : 00000000`00000050 fffff802`0e2f58b0 00000000`00000010 ffff9b80`1006c320 : nt+0x14a6f0
ffff9b80`1006c030 00000000`00000050 : fffff802`0e2f58b0 00000000`00000010 ffff9b80`1006c320 00000000`00000002 : nt+0x19bb54
ffff9b80`1006c038 fffff802`0e2f58b0 : 00000000`00000010 ffff9b80`1006c320 00000000`00000002 fffff802`1e2ea1ec : 0x50
ffff9b80`1006c040 00000000`00000010 : ffff9b80`1006c320 00000000`00000002 fffff802`1e2ea1ec ffffd60d`7c736b48 : 0xfffff802`0e2f58b0
ffff9b80`1006c048 ffff9b80`1006c320 : 00000000`00000002 fffff802`1e2ea1ec ffffd60d`7c736b48 fffff803`af7e420e : 0x10
ffff9b80`1006c050 00000000`00000002 : fffff802`1e2ea1ec ffffd60d`7c736b48 fffff803`af7e420e 00000000`00000000 : 0xffff9b80`1006c320
ffff9b80`1006c058 fffff802`1e2ea1ec : ffffd60d`7c736b48 fffff803`af7e420e 00000000`00000000 00000000`00000007 : 0x2
ffff9b80`1006c060 ffffd60d`7c736b48 : fffff803`af7e420e 00000000`00000000 00000000`00000007 ffffd60d`78051100 : nt+0x611ec
ffff9b80`1006c068 fffff803`af7e420e : 00000000`00000000 00000000`00000007 ffffd60d`78051100 00000000`00000000 : 0xffffd60d`7c736b48
ffff9b80`1006c070 fffff100`00000000 : 00000000`00000000 fffff802`0e2f58b0 00000000`00000010 00000000`00000003 : ACPI!ACPIDispatchIrp+0xce
ffff9b80`1006c0f0 00000000`00000000 : fffff802`0e2f58b0 00000000`00000010 00000000`00000003 ffff9b80`1006c220 : 0xfffff100`00000000


STACK_COMMAND: kb

FOLLOWUP_IP:
ACPI!ACPIDispatchIrp+ce
fffff803`af7e420e 8bf8 mov edi,eax

SYMBOL_STACK_INDEX: 9

SYMBOL_NAME: ACPI!ACPIDispatchIrp+ce

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: ACPI.sys

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner

Nun warte ich auf die detaillierte Auswertung von Ari45! ^^
 
Zuletzt bearbeitet:
Habe soeben beim Overwatch zocken wieder einen Bluescreen bekommen, SYSTEM_SERVICE_EXCEPTION...
Was heißt das nun was du aus den Dumpfiles schließen konntest? Weißst du woran die Bluescreens liegen?
 
"Fehler in der Ausnahmebehandlung von einem Ausführungsprozess"
Es ist die Folge von einem Konfigurationsfehler von Arbeitsspeicher, Mainboard und Prozessor und äußert sich als erkennbares Muster *immer* so, wenn zwischen diesen drei Komponenten der Datenverkehr zur Beeinträchtigung der Datenstruktur führt, die Folge ist der Datenfehler von Instruktionen.


Dumpfile #1:
- Die erste, markierte Zeile besagt den Fehler in der Datenstruktur - das Ende ist der Zugriffsfehler während dem Arbeitsspeicher.
- Die zweite, markierte Zeile besagt den Fehler in der Transaktion zu einem virtuellen Ablagerungsbereich.

Dumpfile #2:
- Die einzige, markierte Zeile besagt den Speicherfehler während der Aufgabenverteilung - ein Fehler in der Transaktion zwischen Speichercontroller und Arbeitsspeicher.


CMOS-Reset ist erfolgt, also sollte ein sich unterdessen eingeschlichener Konfigurationsfehler nicht die Ursache sein, vielmehr liegt die Komplexität in dem IC des Arbeitsspeichers.
 
Vielen dank,
Also habe ich das richtig verstanden, kurzgesagt ein Ram-Stick ist defekt oder hat einen fehler?
 
In Dumpfile #1 ist der Fehler noch vor dem Auslagern von dem Arbeitsspeicher nach UNBEKANNT begründet - die Fehlerquelle ist der Arbeitsspeicher.

In Dumpfile #2 erfolgt die Transaktion - die Aufgabenverteilung - von dem Speichercontroller - die Fehlerquelle ist "annehmlich" der Arbeitsspeicher.
- Der Prozessor fährt seinen Energiezustand herab, weil seine DRAM-Register - zuständig für die Aufgabenverteilung zwischen Speichercontroller und Arbeitsspeicher - auserwählte Aufgaben an den Arbeitsspeicher übergeben - diejenigen Transaktionen zum Arbeitsspeicher nicht verteilt werden oder der Arbeitsspeicher nicht bewältigt und ------------- Explizit ist das nicht erwähnt.

In beiden Richtungen der Transaktionen setzt der Arbeitsspeicher das Schlusslicht - und das bedeutet was?


Bitte warte auf die Auswertung von Ari45, ich brauche noch die Erkenntnis!
 
Zuletzt bearbeitet:
Vielen vielen dank für die hilfe!
haha bin ziemlich ungeduldig wenn es um so etwas geht xD
Hoffe Ari45 meldet sich bald!

Habe jetzt mal einen ram stick aus dem pc genommen und schaue ob es beim zocken immernoch zu einem bluescreen kommt und falls ja wechsle ich den ram stick und schaue ob es an diesem einen ram stick gelegen hat.
 
Hallo und guten Abend!
Ich habe mich nun einige Zeit mit den Dumpfiles beschäftigt. Leider sind 4 von den 5 Dumpfiles unbrauchbar. Ich habe es unter Win8.1-Debugger, Win10-Debugger und dem Online-Debugger versucht. Habe sogar meine Symboldateien neu herunter geladen.
Das Debugg-Ergebnis sieht etwa so aus
***** Kernel symbols are WRONG. Please fix symbols to do analysis.

*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!KPRCB ***
*** ***
*************************************************************************
*************************************************************************
Nur dass noch viele, viele solcher Felder folgen. Dadurch werden keine Funktionsnamen angezeigt, sondern nur Adressen, mit denen man nichts anfangen kann.
Die einzige Dumpfile, die unbeschädigt ist, ist 020117-7765-01.dmp. Und diese schau ich mir jetzt genauer an. Es ist natürlich schade, dass gerade die neuesten Dumpfiles beschädigt sind, aber nicht zu ändern.
 
Hallo Ari45,
stimmt das also nicht was KnSN bei den dump dateien herausgefunden hat?
Also wie gesagt ich habe nun ein RAM stick entnommen und schaue ob es an einem daran liegt.

Nachtrag: ich habe eine neue dump datei von heute, soll ich sie auch mal Anhängen?

LG,FraKing
 
Der Funktionsname ist die Instruktion zu einem String.
Dieser fehlt in den ersten Dumps ausnahmslos.

Weshalb Ari45 gerade auf die erste Datei zu sprechen kommt - meines Wissens trägt diese mit dem Fehler "Bug Check 0x1A: MEMORY_MANAGEMENT" auch nicht vielmehr bei, weil es da genauso ist.

Er hat den Debugger - der die Informationen detaillierter wiedergibt.

Ich füge noch an, dass diese beiden Dumps, die ich verwerten konnte, die letzten beiden sind, also vom 07.02.2017 und 08.02.2017 - wenn das so richtig verblieben ist in meiner Erinnerung.
 
Zuletzt bearbeitet:
Ich habe nicht gesagt, dass das nicht stimmt. In #29 im 2. Spoiler steht so ziemlich am Anfang des Debugger-Logs Wrong_Symbols, also falsche Symbole. Desshalb sind dort im Stack auch auch keine Symbole (also Funktionsnamen), sondern nur nt_XXXXXX (X = Adress-IP).
Hier jetzt die einzige Dumpfile, die sich (sinnvoll) debuggen ließ:
020117-7765-01.dmp
Code: 
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except.
Typically the address is just plain bad or it is pointing at freed memory.
Arguments:
Arg1: fffff8047670049c, memory referenced.
Arg2: 0000000000000010, value 0 = read operation, 1 = write operation.
Arg3: fffff8047670049c, If non-zero, the instruction address which referenced the bad memory
	address.
Arg4: 0000000000000002, (reserved)
......
[COLOR="#008000"]Unter Windows 10 gibt der Debugger erst mal ein paar Systeminfos bekannt. 
Dadurch brauch man nicht extra noch mal die Sysinfo abzufragen[/COLOR]
BUILD_VERSION_STRING:  10.0.14393.206 (rs1_release.160915-0644)
SYSTEM_MANUFACTURER:  MSI
SYSTEM_PRODUCT_NAME:  MS-7A59
SYSTEM_SKU:  Default string
SYSTEM_VERSION:  1.0
BIOS_VENDOR:  American Megatrends Inc.
BIOS_VERSION:  2.00
BIOS_DATE:  12/15/2016
BASEBOARD_MANUFACTURER:  MSI
BASEBOARD_PRODUCT:  Z270 GAMING PRO (MS-7A59)
BASEBOARD_VERSION:  1.0
.....
TRAP_FRAME:  ffff9080fa9f9fb0 -- (.trap 0xffff9080fa9f9fb0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff804f7c4c6b8 rbx=0000000000000000 rcx=ffffb70b37b4e230
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8047670049c rsp=ffff9080fa9fa148 rbp=ffff9080fa9fa250
 r8=0000000000000000  r9=0000000000000003 r10=0000000000000000
r11=fffff804f7c2d84b r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
fffff804`7670049c ??              ???
[COLOR="#008000"]Der Trap ist in diesem Fall nicht besonders hilfreich.[/COLOR]
....
FAILED_INSTRUCTION_ADDRESS: [COLOR="#FF0000"]+0 [/COLOR]fffff804`7670049c [COLOR="#FF0000"]??              ???[/COLOR]
....
STACK_TEXT:  
ffff9080`fa9f9cb8 fffff802`8ca066ca : 00000000`00000050 fffff804`7670049c 00000000`00000010 ffff9080`fa9f9fb0 : nt!KeBugCheckEx
ffff9080`fa9f9cc0 fffff802`8c8f7ffa : 00000000`00000010 00000000`00000000 ffff9080`fa9f9fb0 ffff9080`fa9f9eb9 : nt! ?? ::FNODOBFM::`string'+0x2623a
ffff9080`fa9f9db0 fffff802`8c9da8fc : ffff9080`fa9f9f68 00000000`00000008 ffff9080`fa9f9f80 00000000`00000008 : nt!MmAccessFault+0x9ca
ffff9080`fa9f9fb0 fffff804`7670049c : fffff804`f774a30b 00000000`00000000 ffff9080`fa9fa250 00000000`00000000 : nt!KiPageFault+0x13c
ffff9080`fa9fa148 fffff804`f774a30b : 00000000`00000000 ffff9080`fa9fa250 00000000`00000000 00000000`00008000 : 0xfffff804`7670049c
[COLOR="#FF0000"]ffff9080`fa9fa150 00000000`00000000 : ffff9080`fa9fa250 00000000`00000000 00000000`00008000 ffffb70b`285a45f0 : nvlddmkm+0x10a30b[/COLOR]
[COLOR="#008000"]Der Treiber nvlddmkm.sys hat sofort nach dem Aufruf ein PageFault im Speicher verursacht. 
Dadurch kam es in der Folge zum Zugriffs-Fehler und zum BugCheckEx[/COLOR]
.....
SYMBOL_NAME:  nvlddmkm+10a30b
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: nvlddmkm
[COLOR="#FF0000"]IMAGE_NAME:  nvlddmkm.sys[/COLOR]
....
BUCKET_ID:  AV_INVALID_BAD_IP_nvlddmkm!unknown_function
[COLOR="#FF0000"]PRIMARY_PROBLEM_CLASS:  AV_INVALID_BAD_IP_nvlddmkm!unknown_function[/COLOR]
[COLOR="#008000"]Der NVidia-Kerneltreiber hat eine unbekannte Funktion verwendet, was den Page_Fault auslöste[/COLOR]
....
[COLOR="#008000"]Der Aufruf des aktiven Thread brachte den gleichen Stack, wie weiter oben. Deshalb 
spare ich mir den Thread. 
Zum Schluss noch die Informationen über den NVidia-Treiber[/COLOR]
4: kd> lmvm nvlddmkm
Browse full module list
start             end                 module name
fffff804`f7640000 fffff804`f8454000   nvlddmkm T (no symbols)           
    Loaded symbol image file: nvlddmkm.sys
    Image path: \SystemRoot\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_02838dee03d82b94\nvlddmkm.sys
    Image name: nvlddmkm.sys
    Browse all global symbols  functions  data
    [COLOR="#FF0000"]Timestamp:        Fri Jan 20 14:29:59 2017 [/COLOR](588210D7)
    CheckSum:         00DCBC4D
    ImageSize:        00E14000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
So, mehr ist nicht aus der Dumpfile heraus zu kitzeln.
Meine Schlussfolgerungen:
Der Treiber nvlddmkm.sys benutzt eine Funktion, die Windows nicht bekannt ist. Das kann zum Einen daran liegen, dass Windows nicht up to date ist (BUILD_VERSION_STRING: 10.0.14393.206 (rs1_release.160915-0644) ) und zum Anderen, dass der Treiber fehlerhaft ist.
Nicht immer ist der neueste Treiber auch der beste, stabilste.
Nicht außer Acht zu lassen ist, dass alle diese Aktionen im Speicher (im weitesten Sinne) ausgeführt werden. Deshalb sollte der RAM mit Memtest86+ und die Systempartition mit chkdsk /f überprüft werden. Auch ein Überprüfen der SMART-Werte der SSD/HDD kann Gewißheit bringen, dass der Datenträger in Ordnung ist.
 
Zuletzt bearbeitet:
@Ari45

Ich hab den Treiber nicht berücksichtigt, weil der Kernel-Inpage nach dem Speicherzugriffsfehler referenziert ist.
Ist das verkehrt gewesen?
 
Dann werde ich nun als nächtes mal meinen Ram mit memtest86+ überprüfen, vielen dank
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Anzeige
Oben