{"id":7263,"date":"2012-02-03T03:04:00","date_gmt":"2012-02-03T01:04:00","guid":{"rendered":"http:\/\/www.borncity.com\/blog\/2012\/02\/03\/windows-bluescreen-analyse-teil-3\/"},"modified":"2025-08-16T18:10:40","modified_gmt":"2025-08-16T16:10:40","slug":"windows-bluescreen-analyse-teil-3","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2012\/02\/03\/windows-bluescreen-analyse-teil-3\/","title":{"rendered":"Windows BlueScreen-Analyse – Teil 3"},"content":{"rendered":"

In Teil 1<\/a> habe ich skizziert, wie sich ein automatisch startendes System so disziplinieren l\u00e4sst, dass der Benutzer die Meldungen eines Blue Screens ablesen kann. In Teil\u00a0 2<\/a> wurde gezeigt, wo Dump-Dateien gespeichert werden und wie sich deren Optionen anpassen lassen. Nun m\u00f6chte ich auf die Auswertung von .dmp-Dateien eingehen.<\/p>\n

<\/p>\n

Dump-Dateien mit dem BlueScreenView analysieren<\/h3>\n

\"\"Zur schnellen Analyse einer Dump-Datei l\u00e4sst sich das Tool BlueScreenView von Nirsoft verwenden. Das Programm kann kostenlos von dieser Webseite<\/a> heruntergeladen werden. Das Programm liest nach dem Start automatisch die .dmp-Dateien aus dem Windows-Ordner Minidump<\/em> aus. Der Ordner l\u00e4sst sich aber \u00fcber die Schaltfl\u00e4che Advanced Options <\/em>der Symbolleiste anpassen.<\/p>\n

\"\"<\/p>\n

Anschlie\u00dfend zeigt es die Modulliste sowie eventuell die Eintr\u00e4ge, die den Fehler verursachen, an. Alternativ kann der BlueScreen abgerufen werden. Die Auswahl der Darstellung erfolgt \u00fcber das Untermen\u00fc Lower Pane Mode <\/em>des Men\u00fcs Options<\/em>.<\/p>\n

In manchen F\u00e4llen kann mit diesem Ansatz die Ursache f\u00fcr den BSOD auf die Spur. Allerdings hat BlueScreenView seine Grenzen und zeigt gelegentlich sogar in die falsche Richtung. Hier kommt man nur mit einer Analyse der .dmp-Datei per WinDbg weiter.<\/p>\n

Wo bekomme ich WinDbg her?<\/strong><\/h3>\n

Der Windows-Debugger WinDbg wird von Microsoft kostenlos im Rahmen des Windows SDK angeboten [a, b]. Unter [c<\/a>] hat Microsoft einen Artikel zum Installieren mit den Download-Links ver\u00f6ffentlicht. Allerdings ist es etwas doof, ein mehrere hundert Megabyte gro\u00dfes SDK herunterzuladen, nur um einen Debugger installieren zu k\u00f6nnen.<\/p>\n

Nach ein wenig Suche bin ich aber auf die unter [d<\/a>] verlinkte Blogseite gesto\u00dfen. Dort finden sich Links, um die Windows-Debugger in einer 32- oder 64-Bit-Version als Standalone-Version herunterzuladen. Nach dem Entpacken der ZIP-Archive l\u00e4sst sich der Debugger installieren. Weiterhin gibt es das unter [e] verlinkte MSDN-Archiv, in dem sich die installierbaren .msi-Dateien befinden.<\/p>\n

Achten Sie lediglich darauf, einen 64-Bit-Debugger zu verwenden, um Dump-Dateien von 32- und 64-Bit-Systemen zu analysieren. Bei Dump-Dateien von 32-Bit-Systemen l\u00e4sst sich auch ein 32-Bit-Debugger einsetzen.<\/p>\n

a: Debugging Tools for Windows 32-bit Versions
\nb: Debugging Tools for Windows 64-bit Versions
\nc: Download and Install Debugging Tools for Windows<\/a>
\nd: Standalone windbg Downloads<\/a>
\ne: Standalone windbg Downloads (MSDN-Archiv)<\/p>\n

WinDbg einrichten<\/h3>\n

Ist WinDbg installiert, muss das Programm vor der ersten Verwendung eingerichtet werden. Hierzu starten Sie WinDbg, \u00f6ffnen das Men\u00fc Datei<\/em> und w\u00e4hlen den Befehl Symbol File Path<\/em>.<\/p>\n

\"\"<\/p>\n

Anschlie\u00dfend tragen Sie im Dialogfeld Symbol File Path <\/em>den String zum Symbolcache und zum Download-Pfad ein.<\/p>\n

srv*c:\\cache*http:\/\/msdl.microsoft.com\/download\/symbols<\/em><\/p>\n

Das Sternchen in obigem String f\u00fcllt die Leerzeichen im String. Die Angabe c:\\cache<\/em> legt den Pfad zum Symbolcache fest. Hier habe ich einen Ordner cache <\/em>auf dem Laufwerk C: verwendet. Mit der Angabe:<\/p>\n

http:\/\/msdl.microsoft.com\/download\/symbols<\/em><\/p>\n

wird die Download-Adresse f\u00fcr die Symboldateien festgelegt. Dieser String muss korrekt definiert werden. Sie k\u00f6nnen sich unter [g<\/a>] zus\u00e4tzliche Symboldateien f\u00fcr diverse Windows-Versionen lokal herunterladen und dann in den Cache-Ordner kopieren. Dies hat den Vorteil, dass der Debugger sofort \u00fcber die ben\u00f6tigten Symbolpakete verf\u00fcgt \u2013 es muss nichts online vom Symbol-Server heruntergeladen werden. Zudem scheinen diese Symbolpakete vollst\u00e4ndiger als die Pakete des Symbol-Servers zu sein. Nachteil ist aber, dass die Pakete recht umfangreich (750 MB bis 1 GB) sein k\u00f6nnen.<\/p>\n

f: Debugger einrichten<\/a> und debuggen
\ng: Zus\u00e4tzliche Symboldateien<\/a> MSDN-Download-Seite
\nh: Debug-Symbole herunterladen<\/a><\/p>\n

\n

Achtung:<\/strong> Die im Internet zu findenden Anleitungen (z. B. hier<\/a> und hier<\/a>) zum Festlegen dieses Strings sind teilweise problematisch, weil oft Fragezeichen, Anf\u00fchrungszeichen oder Blanks im Beispielstring verwendet werden. Ich habe viele Stunden der Fehlersuche verbracht, weil der Debugger nicht korrekt funktionierte. Beim hier<\/a> verlinkten Beitrag sind die Screenshots zwar korrekt. Man sollte man das Video am Ende (wo es um die Interpretation der Ergebnisse geht) aber mit Vorsicht genie\u00dfen.<\/p>\n

Hinweis:<\/strong> Wird beim Debuggen der Text \"Debuggee not connected\" in der Statusleiste angezeigt? Dies ist kein Grund zur Sorge, der Debugger l\u00e4dt dann Symboldateien, was eine Zeitlang dauern kann.<\/p>\n<\/blockquote>\n

Dump-Dateien analysieren<\/h3>\n

Ist WinDbg eingerichtet, lassen sich .dmp-Dateien analysieren. Hierzu kopieren Sie die .dmp-Datei in einen lokalen Ordner und starten den Debugger WinDbg. Anschlie\u00dfend \u00f6ffnen Sie das Men\u00fc File <\/em>und w\u00e4hlen den Befehl Open Crash Dump<\/em>. Dann ist die .dmp-Datei im Dialogfeld Open Crash Dump<\/em> auszuw\u00e4hlen und \u00fcber die \u00d6ffnen<\/em>-Schaltfl\u00e4che zu laden.<\/p>\n

\"\"<\/p>\n

Anschlie\u00dfend sollten die Dump-Inhalte angezeigt werden. Hier ist das Fenster des Debuggers mit der Auswertung eines Dumps zu sehen. Am unteren Fensterrand findet sich ein Statusangabe (hier *BUSY*, d. h. WinDbg arbeitet noch) sowie ein Textfeld zur Befehlseingabe.##<\/p>\n

\"\"<\/a><\/p>\n

Im aktuellen Fall wird gemeldet, dass die Dump-Datei eine Ausnahme (Exception) aufweist. Diese kann mittels des Befehls .ecxr. <\/em>ausgewertet werden. Hier ein Auszug aus einer solchen Auswertung:<\/p>\n

This dump file has an exception of interest stored in it.
\nThe stored exception information can be accessed via .ecxr.
\n(d48.85c): Access violation - code c0000005 (first\/second chance not available)
\neax=00000000 ebx=05e328b0 ecx=0768c3b0 edx=0523faf0 esi=05e32870 edi=0523ef30
\neip=77590be2 esp=0523ebf0 ebp=0523ec00 iopl=0\u00a0\u00a0\u00a0 nv up ei pl nz na pe nc
\ncs=0023\u00a0 ss=002b\u00a0 ds=002b\u00a0 es=002b\u00a0 fs=0053\u00a0 gs=002b\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 efl=00010206
\nntdll!NtGetContextThread+0x12:
\n77590be2 83c404\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 add\u00a0\u00a0\u00a0\u00a0 esp,4
\n0:002> .ecxr.
\neax=3031007d ebx=31333837 ecx=0768c3b0 edx=0523faf0 esi=0768c3b0 edi=0523faf0
\neip=111a7135 esp=0523faac ebp=0523fad4 iopl=0\u00a0\u00a0 nv up ei pl nz na pe nc
\ncs=0023\u00a0 ss=002b s=002b es=002b\u00a0 fs=0053\u00a0 gs=002b\u00a0\u00a0\u00a0 efl=00010206
\nUnable to load image C:\\Program Files
\n(x86)\\VMware\\VMware Player\\vmwarebase.DLL, Win32 error 0n2
\n*** WARNING: Unable to verify timestamp for vmwarebase.DLL
\n*** ERROR: Module load completed but symbols could not be loaded for vmwarebase.DLL
\nvmwarebase+0xa7135:
\n111a7135 8b7004 mov esi,dword ptr [eax+4] ds:002b:30310081=????????
\n^ Extra character error in '.ecxr.'<\/span><\/code><\/p>\n

Mit dem im Testfeld eingegebenen Befehl !analyze \u2013v <\/em>l\u00e4sst sich eine weitgehend automatisierte Analyse des Dumps starten. Besteht eine Online-Verbindung, versucht der Debugger Kontakt zu einem Microsoft-Server aufzunehmen, um Crash-L\u00f6sungen aus einer Datenbank zu beziehen. Hier ein Auszug aus einer solchen Analyse:<\/p>\n

0:002> !analyze \u2013v<\/span>
\n*******************************************************************************
\n*
\n*
\n<\/span>*\u00a0 Exception Analysis
\n*
\n*
\n*<\/span>******************************************************************************
\n<\/span><\/p>\n

 <\/p>\n

*** WARNING: Unable to verify timestamp for vmdbCOM.dll
\n<\/span>*** ERROR: Module load completed but symbols could not be
\nloaded for vmdbCOM.dll
\n*** WARNING: Unable to verify timestamp for vmplayer.exe
\n*** ERROR: Module load completed but symbols could not be
\nloaded for vmplayer.exe
\n*** WARNING: Unable to verify timestamp for shell32.dll
\nGetPageUrlData failed, server returned HTTP status 404
\n<\/span>URL requested:
\n<\/span>
\nvmwarebase_DLL\/7_0_1_11056\/4b5a7259\/c0000005\/000a7135.htm?Retriage=1 <\/span><\/code><\/p>\n

FAULTING_IP:
\n<\/span>vmwarebase+a7135
\n<\/span>111a7135 8b7004\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 mov\u00a0\u00a0\u00a0\u00a0 esi,dword ptr [eax+4]
\n<\/span>
\nEXCEPTION_RECORD:\u00a0 ffffffff — (.exr 0xffffffffffffffff) <\/span><\/p>\n

ExceptionAddress: 111a7135 (vmwarebase+0x000a7135)<\/span><\/p>\n

ExceptionCode: c0000005 (Access violation)<\/span><\/p>\n

ExceptionFlags: 00000000<\/p>\n

NumberParameters: 2<\/p>\n

Parameter[0]: 00000000
\nParameter[1]: 30310081<\/p>\n

Attempt to read from address 30310081 <\/span><\/p>\n

PROCESS_NAME:\u00a0 vmplayer.exe <\/span><\/p>\n

ERROR_CODE: (NTSTATUS) 0xc0000005 – Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden. <\/span><\/p>\n

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 – Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden. <\/span><\/p>\n

EXCEPTION_PARAMETER1:\u00a0 00000000 <\/span><\/p>\n

EXCEPTION_PARAMETER2:\u00a0 30310081 <\/span><\/p>\n

READ_ADDRESS:\u00a0 30310081 <\/span><\/p>\n

FOLLOWUP_IP: <\/span><\/p>\n

vmwarebase+a7135<\/p>\n

111a7135 8b7004\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 mov\u00a0\u00a0\u00a0\u00a0 esi,dword ptr [eax+4] <\/span><\/p>\n

MOD_LIST: <ANALYSIS\/> <\/span><\/p>\n

APPLICATION_VERIFIER_FLAGS:\u00a0 0 <\/span><\/p>\n

FAULTING_THREAD:\u00a0 0000085c <\/span><\/p>\n

BUGCHECK_STR:\u00a0 APPLICATION_FAULT_ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_
\nnot_busy_INVALID_POINTER_READ <\/span><\/p>\n

PRIMARY_PROBLEM_CLASS:\u00a0 ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_not_busy <\/span><\/p>\n

DEFAULT_BUCKET_ID:\u00a0 ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_not_busy <\/span><\/p>\n

LAST_CONTROL_TRANSFER:\u00a0 from 111a063a to 111a7135 <\/span><\/p>\n

STACK_TEXT:\u00a0 <\/span><\/p>\n

WARNING: Stack unwind information not available. Following frames
\nmay be wrong.<\/p>\n

0523fad4 111a063a 0523faf0 026d6170 00000000 vmwarebase+0xa7135
\n0523fb18 111a0958 055d7220 026d6170 055d7220 vmwarebase+0xa063a
\n0523fb38 111a0f5c 026d6170 05433840 054a09b8 vmwarebase+0xa0958
\n0523fc9c 111a7b1d 05801778 026d82a0 026d7e58 vmwarebase+0xa0f5c
\n0523fcdc 1101a342 00000001 01770000 0523ff88 vmwarebase+0xa7b1d
\n0523fcec 1101a54a 02020002 536e6957 206b636f vmdbCOM+0x1a342
\n0523ff88 76bf3677 00000002 0523ffd4 775a9d72 vmdbCOM+0x1a54a<\/p>\n

0523ff94 775a9d72 026d7e58 7221c32b 00000000
\nkernel32!BaseThreadInitThunk+0xe
\n0523ffd4 775a9d45 1101a480 026d7e58 00000000
\nntdll!__RtlUserThreadStart+0x70
\n0523ffec 00000000 1101a480 026d7e58 00000000
\nntdll!_RtlUserThreadStart+0x1b <\/span><\/p>\n

STACK_COMMAND:\u00a0 !heap ; ~2s; .ecxr ; kb <\/span><\/p>\n

SYMBOL_STACK_INDEX:\u00a0 0 <\/span><\/p>\n

SYMBOL_NAME:\u00a0 vmwarebase+a7135 <\/span><\/p>\n

FOLLOWUP_NAME:\u00a0 MachineOwner <\/span><\/p>\n

MODULE_NAME: vmwarebase <\/span><\/p>\n

IMAGE_NAME:\u00a0 vmwarebase.DLL <\/span><\/p>\n

DEBUG_FLR_IMAGE_TIMESTAMP:\u00a0 4b5a7259 <\/span><\/p>\n

FAILURE_BUCKET_ID:\u00a0 ACTIONABLE_HEAP_CORRUPTION_heap_failure_block_not_busy_
\nc0000005_vmwarebase.DLL!Unknown <\/span><\/p>\n

BUCKET_ID:\u00a0 APPLICATION_FAULT_ACTIONABLE_HEAP_CORRUPTION<\/strong>_heap_failure_
\nblock_not_busy_INVALID_POINTER_READ_vmwarebase+a7135 <\/span><\/p>\n

WATSON_STAGEONE_URL:\u00a0 <\/span>
\n4b5a7e23\/vmwarebase_DLL\/7_0_1_11056\/4b5a7259\/c0000005\/000a7135.htm?Retriage=1<\/span><\/p>\n

Followup: MachineOwner<\/span><\/p>\n

——— <\/span><\/p>\n

An Hand der so ausgeworfenen Informationen gilt es nun, die Fehlerursache zu analysieren.<\/p>\n

\n

Hinweis:<\/strong> Beachten Sie, dass der Zugriff auf die Datenbank und die Analyse der Dump-Dateien eine ganze Zeit dauern kann. Die Anzeige *BUSY* <\/em>im Statusbereich des Debugger-Fensters signalisiert, dass der Debugger noch mit der Analyse befasst ist. Der Text Debuggee not connected <\/em>im Textfeld der Statusleiste ist ein Hinweis, dass keine Verbindung zum Microsoft-Symbolserver bzw. zur Dump-Datei besteht. Bei mir tritt diese Meldung z. B. auf, wenn der Debugger gestartet aber noch keine Dump-Datei geladen ist. Der zweite Fall f\u00fcr die Meldung liegt vor, wenn Symboldateien vom Microsoft-Server heruntergeladen werden m\u00fcssen. Die Meldungen sollten aber nach einer gewissen Wartezeit verschwinden. Zudem habe ich zusammen mit Michael Bormann die Erfahrung gemacht, dass die heruntergefahren Symboldateien durchaus auch schon mal besch\u00e4digt werden k\u00f6nnen \u2013 so dass WinDbg bei der Analyse Mist macht. Dann hilft nur noch, den Symbol-Cache zu l\u00f6schen und die Symbollisten neu aufbauen zu lassen.<\/p>\n<\/blockquote>\n

Die Kunst ist es nun, m\u00f6glichst viele Informationen \u00fcber das System zu erhalten. Mit dem Befehl !sysinfo cpuinfo<\/em> sollten CPU-Informationen angezeigt werden.<\/p>\n

Mit dem Befehl lmnt<\/em> l\u00e4sst sich die Modulliste abrufen. Diese gibt u. U. Hinweise, ob \u00e4ltere Module (Treiber) oder andere problematische Komponenten geladen sind und der Grund f\u00fcr den BlueScreen sein k\u00f6nnen.\u00a0 Hier ein Auszug aus einer solchen Liste<\/p>\n

0:036> lmnt
\nstart\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 end\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 module name
\n00000000`02580000 00000000`0259c000\u00a0\u00a0 MACDRAPI MACDRAPI.DLL<\/span> Tue May 06 21:02:43 2008 <\/span>(4820AB53)
\n00000000`02d80000 00000000`02da5000\u00a0\u00a0 XPCopyHook XPCopyHook.dll Thu Dec 17 21:33:30 2009 (4B2A959A)
\n00000000`09b70000 00000000`09d42000\u00a0\u00a0 nvui\u00a0\u00a0\u00a0\u00a0 nvui.dll\u00a0\u00a0\u00a0\u00a0 Sat Oct 16 19:03:07 2010 (4CB9DACB)<\/span><\/code><\/p>\n

Es wird hier eine DLL aus dem Jahr 2008 verwendet, obwohl Windows 7 erst 2009 ver\u00f6ffentlicht wurde. Der Debugger kennt eine Reihe weiterer Befehle, um die Dump-Datei zu analysieren.<\/p>\n

\n

Tipp:<\/strong> Soll das Debuggen beendet und eine neue .dmp-Datei geladen werden, m\u00fcssen Sie den Debugger erst stoppen. Die betreffenden Befehle finden Sie im Men\u00fc Debugg.<\/em><\/p>\n<\/blockquote>\n

Wo gibt's Hinweise zu WinDbg und zur BSOD-Analyse?<\/h3>\n

Das Einrichten und die Bedienung des Debuggers ist in der WinDbg-Hilfe beschrieben (aufrufbar \u00fcber das Hilfe-Men\u00fc des Debugger-Fenstes). In der WinDbg-Hilfe finden Sie auch Hinweise, wie sich Dump-Dateien analysieren lassen.<\/p>\n

\"\"<\/a><\/p>\n

Zudem gibt es unter [i<\/a>] weitere Hinweise, wie sich Dump-Dateien analysieren lassen.<\/p>\n

i: www.windbg.org<\/a> Debugging Infos
\nj: Debug-Hinweise<\/a>
\nk: Weitere Debug-Analyse-Hinweise<\/a><\/p>\n

B\u00fccher zu Dump-Analyse<\/h3>\n

Wer mehr \u00fcber die Analyse von .dmp-Dateien erfahren m\u00f6chte, findet im BOD-Titel \"In den Abgrund gezogen\" eine Anleitung. Auf 164 Seiten beschreibt Michael Bormann, Ex-Microsoft MVP und Microsoft Answers-Communitymoderator, die Analyse von Dump-Dateien zur BlueScreen-Ursachenanalyse in deutsch. Details sind hier<\/a> (oder auf Amazon<\/a>) zu finden. Erg\u00e4nzung: Michael Bormann ist inzwischen verstorben, es wird also keine Neuauflage geben.<\/p>\n\n\n\n
wohl nicht mehr erh\u00e4ltlich, da BOD, und der Autor ist verstorben<\/td>\nMichael Bormann: In den Abgrund gezogen
\n<\/strong>ISBN 978-3-8448-1742-3, Paperback,
\n168 Seiten<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\u00c4hnliche Artikel:<\/strong>
\n1: Windows BlueScreen-Analyse<\/a> \u2013 Teil 1
\n2: Windows BlueScreen-Analyse<\/a> \u2013 Teil 2
\n3: Windows BlueScreen-Analyse<\/a> \u2013 Teil 3<\/p>\n","protected":false},"excerpt":{"rendered":"

In Teil 1 habe ich skizziert, wie sich ein automatisch startendes System so disziplinieren l\u00e4sst, dass der Benutzer die Meldungen eines Blue Screens ablesen kann. In Teil\u00a0 2 wurde gezeigt, wo Dump-Dateien gespeichert werden und wie sich deren Optionen anpassen … Weiterlesen →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[1845,1846,3288],"class_list":["post-7263","post","type-post","status-publish","format-standard","hentry","category-allgemein","tag-blue-screen-analyse","tag-debugger","tag-windows-en"],"_links":{"self":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/7263","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/comments?post=7263"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/7263\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/media?parent=7263"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/categories?post=7263"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/tags?post=7263"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}