లాగ్‌లు ఎక్కడ నుండి వస్తాయి? వీమ్ లాగ్ డైవింగ్

మేము ఊహించడం ... లాగ్‌ల ద్వారా ట్రబుల్షూటింగ్ యొక్క మనోహరమైన ప్రపంచంలోకి మా లీనాన్ని కొనసాగిస్తాము. IN మునుపటి వ్యాసం మేము ప్రాథమిక నిబంధనల అర్థాన్ని అంగీకరించాము మరియు వీమ్ యొక్క మొత్తం నిర్మాణాన్ని ఒకే అప్లికేషన్‌గా ఒకే కన్నుతో చూశాము. లాగ్ ఫైల్‌లు ఎలా ఏర్పడతాయో, వాటిలో ఎలాంటి సమాచారం ప్రదర్శించబడుతుందో మరియు అవి ఎందుకు కనిపిస్తున్నాయో గుర్తించడం దీనికి సంబంధించిన పని.

ఈ "లాగ్‌లు" ఏమిటని మీరు అనుకుంటున్నారు? చాలా మంది అభిప్రాయం ప్రకారం, ఏదైనా అప్లికేషన్ యొక్క లాగ్‌లు ఒక రకమైన సర్వశక్తిమంతమైన సంస్థ యొక్క పాత్రను కేటాయించాలి, అది ఎక్కువ సమయం ఎక్కడో పెరట్లో వృక్షాలుగా ఉంటుంది, కానీ సరైన సమయంలో మెరుస్తున్న కవచంలో ఎక్కడా కనిపించదు మరియు ప్రతి ఒక్కరినీ రక్షిస్తుంది. అంటే, అవి ప్రతి అంశంలో చిన్నపాటి లోపాల నుండి వ్యక్తిగత డేటాబేస్ లావాదేవీల వరకు అన్నింటినీ కలిగి ఉండాలి. మరియు లోపం తర్వాత దాన్ని ఎలా పరిష్కరించాలో వెంటనే వ్రాయబడింది. మరియు ఇవన్నీ రెండు మెగాబైట్‌లలో సరిపోతాయి, ఇక లేదు. ఇది కేవలం వచనం మాత్రమే! టెక్స్ట్ ఫైల్‌లు పదుల గిగాబైట్‌లను తీసుకోలేవు, నేను ఎక్కడో విన్నాను!

కాబట్టి లాగ్‌లు

వాస్తవ ప్రపంచంలో, లాగ్‌లు డయాగ్నస్టిక్ సమాచారం యొక్క ఆర్కైవ్ మాత్రమే. మరియు అక్కడ ఏమి నిల్వ చేయాలి, నిల్వ కోసం సమాచారాన్ని ఎక్కడ పొందాలి మరియు అది ఎంత వివరంగా ఉండాలి, డెవలపర్లు స్వయంగా నిర్ణయించుకోవాలి. ఎవరైనా ఆన్ / ఆఫ్ స్థాయి రికార్డులను ఉంచడం ద్వారా మినిమలిజం యొక్క మార్గాన్ని అనుసరిస్తారు మరియు ఎవరైనా వారు చేరుకోగలిగే ప్రతిదాన్ని శ్రద్ధగా రేక్ చేస్తారు. లాగింగ్ లెవెల్ అని పిలవబడే సామర్థ్యాన్ని ఎంచుకునే సామర్థ్యంతో ఇంటర్మీడియట్ ఎంపిక కూడా ఉన్నప్పటికీ, మీరు ఎంత వివరణాత్మక సమాచారాన్ని నిల్వ చేయాలనుకుంటున్నారు మరియు మీకు ఎంత అదనపు డిస్క్ స్థలం ఉందో మీరే సూచించినప్పుడు =) VBR అటువంటి ఆరు స్థాయిలను కలిగి ఉంది. మరియు, నన్ను నమ్మండి, మీ డిస్క్‌లో ఖాళీ స్థలంతో అత్యంత వివరణాత్మక లాగింగ్‌తో ఏమి జరుగుతుందో మీరు చూడకూడదు.

ఫైన్. మేము ఏమి సేవ్ చేయాలనుకుంటున్నాము అని మేము దాదాపుగా అర్థం చేసుకున్నాము, కానీ చట్టబద్ధమైన ప్రశ్న తలెత్తుతుంది: ఈ సమాచారాన్ని ఎక్కడ నుండి పొందాలి? వాస్తవానికి, మా అంతర్గత ప్రక్రియల ద్వారా మమ్మల్ని లాగింగ్ చేయడానికి మేము ఈవెంట్‌లలో భాగంగా ఉంటాము. కానీ బాహ్య వాతావరణంతో పరస్పర చర్య ఉన్నప్పుడు ఏమి చేయాలి? క్రచెస్ మరియు సైకిళ్ల పిచ్ హెల్‌లోకి జారిపోకుండా ఉండటానికి, వీమ్ ఇప్పటికే కనుగొనబడిన ఆవిష్కరణలను కనుగొనలేదు. రెడీమేడ్ API, అంతర్నిర్మిత ఫంక్షన్, లైబ్రరీ మొదలైనవి ఉన్నప్పుడల్లా, మా కాంట్రాప్షన్‌లకు కంచె వేయడం ప్రారంభించే ముందు మేము రెడీమేడ్ ఎంపికలకు ప్రాధాన్యత ఇస్తాము. రెండోది కూడా సరిపోతుంది. అందువల్ల, లాగ్‌లను విశ్లేషించేటప్పుడు, థర్డ్-పార్టీ APIలు, సిస్టమ్ కాల్‌లు మరియు ఇతర లైబ్రరీల నుండి వచ్చే సందేశాలపై సింహభాగం లోపాలు పడతాయని అర్థం చేసుకోవడం ముఖ్యం. ఈ సందర్భంలో, VBR యొక్క పాత్ర ఈ లోపాలను లాగ్ ఫైల్‌లకు ఫార్వార్డ్ చేయడానికి వస్తుంది. మరియు వినియోగదారు యొక్క ప్రధాన పని ఏమిటంటే, ఏ లైన్ ఎవరి నుండి వచ్చిందో మరియు ఈ “ఎవరు” బాధ్యత వహిస్తారో అర్థం చేసుకోవడం నేర్చుకోవడం. కాబట్టి VBR లాగ్ నుండి ఎర్రర్ కోడ్ మిమ్మల్ని MSDN పేజీకి తీసుకెళ్తే, అది మంచిది మరియు సరైనది.

మేము ముందుగా అంగీకరించినట్లుగా: వీమ్ అనేది SQL-ఆధారిత అప్లికేషన్ అని పిలవబడేది. దీని అర్థం అన్ని సెట్టింగులు, మొత్తం సమాచారం మరియు సాధారణంగా సాధారణ పనితీరు కోసం మాత్రమే అవసరమైన ప్రతిదీ - ప్రతిదీ దాని డేటాబేస్లో నిల్వ చేయబడుతుంది. అందువల్ల సాధారణ నిజం: లాగ్‌లలో లేనిది డేటాబేస్‌లో ఎక్కువగా ఉంటుంది. కానీ ఇది వెండి బుల్లెట్ కూడా కాదు: కొన్ని విషయాలు వీమ్ భాగాల స్థానిక లాగ్‌లలో లేదా దాని డేటాబేస్‌లో లేవు. అందువల్ల, మీరు హోస్ట్ లాగ్‌లు, స్థానిక యంత్రం యొక్క లాగ్‌లు మరియు బ్యాకప్ మరియు పునరుద్ధరణ ప్రక్రియలో పాల్గొన్న ప్రతిదాని లాగ్‌లను ఎలా అధ్యయనం చేయాలో నేర్చుకోవాలి. మరియు అవసరమైన సమాచారం ఎక్కడా అందుబాటులో లేదని కూడా ఇది జరుగుతుంది. అదే దారి. 

అటువంటి APIల యొక్క కొన్ని ఉదాహరణలు

ఈ జాబితా అనూహ్యంగా పూర్తి కావాలనే లక్ష్యంతో లేదు, కాబట్టి దానిలో అంతిమ సత్యం కోసం వెతకవలసిన అవసరం లేదు. మా ఉత్పత్తులలో ఉపయోగించే అత్యంత సాధారణ మూడవ పక్ష APIలు మరియు సాంకేతికతలను చూపడం మాత్రమే దీని ఉద్దేశ్యం.

దీనితో ప్రారంభిద్దాం VMware. 

జాబితాలో మొదటి స్థానంలో ఉంటుంది vSphere API. ప్రామాణీకరణ, సోపానక్రమాన్ని చదవడం, స్నాప్‌షాట్‌లను సృష్టించడం మరియు తొలగించడం, యంత్రాల గురించి సమాచారాన్ని అభ్యర్థించడం మరియు చాలా (చాలా ఎక్కువ) కోసం ఉపయోగించబడుతుంది. పరిష్కారం యొక్క కార్యాచరణ చాలా విస్తృతమైనది, కాబట్టి నేను సంస్కరణ కోసం VMware vSphere API సూచనను సిఫార్సు చేయగలను 5.5 и 6.0. మరిన్ని ప్రస్తుత సంస్కరణల కోసం, ప్రతిదీ కేవలం గూగుల్ చేయబడింది.

VIX API. హైపర్‌వైజర్ యొక్క బ్లాక్ మ్యాజిక్, దాని కోసం ప్రత్యేకంగా ఉంది దోష జాబితా. నెట్‌వర్క్‌లో ఫైల్‌లకు కనెక్ట్ చేయకుండా హోస్ట్‌లోని ఫైల్‌లతో పని చేయడానికి VMware API. మెరుగైన కమ్యూనికేషన్ ఛానెల్ లేని మెషీన్‌లో మీరు ఫైల్‌ను ఉంచాల్సిన అవసరం వచ్చినప్పుడు చివరి రిసార్ట్ యొక్క వైవిధ్యం. ఫైల్ పెద్దది మరియు హోస్ట్ లోడ్ అయినట్లయితే ఇది నొప్పి మరియు బాధ. కానీ ఇక్కడ 56,6 Kb / s కంటే 0 Kb / s కూడా మెరుగ్గా ఉంటుందని నియమం పనిచేస్తుంది. హైపర్-విలో, ఈ విషయాన్ని పవర్‌షెల్ డైరెక్ట్ అంటారు. కానీ అది అంతకు ముందు మాత్రమే

vSpehere వెబ్ సేవల API vSphere 6.0తో ప్రారంభించి (సుమారుగా ఈ API వెర్షన్ 5.5లో ప్రవేశపెట్టబడినప్పటి నుండి) ఇది అతిథి యంత్రాలతో పని చేయడానికి ఉపయోగించబడుతుంది మరియు దాదాపు ప్రతిచోటా VIXని భర్తీ చేసింది. నిజానికి, ఇది vSphereని నిర్వహించడానికి మరొక API. ఆసక్తి ఉన్నవారికి, నేను చదువుకోవాలని సిఫార్సు చేస్తున్నాను отличный మాన్యువల్. 

VDDK (వర్చువల్ డిస్క్ డెవలప్‌మెంట్ కిట్). ఇందులో పాక్షికంగా చర్చించబడిన గ్రంథాలయం వ్యాసం. వర్చువల్ డిస్క్‌లను చదవడానికి ఉపయోగిస్తారు. ఒకప్పుడు ఇది VIXలో భాగం, కానీ కాలక్రమేణా అది ప్రత్యేక ఉత్పత్తికి తరలించబడింది. కానీ వారసుడిగా, ఇది VIX వలె అదే లోపం కోడ్‌లను ఉపయోగిస్తుంది. కానీ కొన్ని కారణాల వల్ల, SDKలోనే ఈ లోపాల గురించి వివరణ లేదు. అందువల్ల, ఇతర కోడ్‌లతో VDDK లోపాలు బైనరీ నుండి దశాంశ కోడ్‌కు అనువాదం మాత్రమే అని అనుభవపూర్వకంగా కనుగొనబడింది. ఇది రెండు భాగాలను కలిగి ఉంటుంది - మొదటి సగం సందర్భం గురించి నమోదుకాని సమాచారం మరియు రెండవ భాగం సాంప్రదాయ VIX / VDDK లోపాలు. ఉదాహరణకు, మనం చూస్తే:

VDDK error: 21036749815809.Unknown error

అప్పుడు మేము దీన్ని ధైర్యంగా హెక్స్‌గా మారుస్తాము మరియు 132200000001ని పొందుతాము. మేము 132200 యొక్క సమాచారం లేని ప్రారంభాన్ని విస్మరిస్తాము మరియు మిగిలినది మా ఎర్రర్ కోడ్ (VDDK 1: తెలియని లోపం). చాలా తరచుగా జరిగే VDDK ఎర్రర్‌ల గురించి, ఇటీవలే వేరుగా ఉన్నాయి వ్యాసం.

ఇప్పుడు చూద్దాం విండోస్.

ఇక్కడ, మనకు అత్యంత అవసరమైన మరియు ముఖ్యమైన ప్రతిదీ ప్రమాణంలో కనుగొనవచ్చు ఈవెంట్ వ్యూయర్. కానీ ఒక క్యాచ్ ఉంది: సుదీర్ఘ సంప్రదాయం ప్రకారం, విండోస్ లోపం యొక్క పూర్తి పాఠాన్ని లాగ్ చేయదు, కానీ దాని సంఖ్య మాత్రమే. ఉదాహరణకు, లోపం 5 “యాక్సెస్ నిరాకరించబడింది” మరియు 1722 “RPC సర్వర్ అందుబాటులో లేదు” మరియు 10060 “కనెక్షన్ సమయం ముగిసింది”. అయితే, మీరు చాలా ప్రసిద్ధి చెందిన వాటిని గుర్తుంచుకుంటే చాలా బాగుంది, కానీ ఇప్పటివరకు చూడని వాటి గురించి ఏమిటి? 

మరియు జీవితం తేనెలా కనిపించకుండా ఉండటానికి, లోపాలు హెక్సాడెసిమల్ రూపంలో 0x8007 ఉపసర్గతో నిల్వ చేయబడతాయి. ఉదాహరణకు, 0x8007000e వాస్తవానికి 14, మెమరీ ముగిసింది. ఇది ఎందుకు మరియు ఎవరి కోసం జరిగింది అనేది చీకటిలో కప్పబడిన రహస్యం. అయినప్పటికీ, లోపాల యొక్క పూర్తి జాబితాను ఉచితంగా మరియు SMS లేకుండా డౌన్‌లోడ్ చేసుకోవచ్చు devcenter.

మార్గం ద్వారా, కొన్నిసార్లు ఇతర ఉపసర్గలు ఉన్నాయి, కేవలం 0x8007 మాత్రమే కాదు. అటువంటి విచారకరమైన పరిస్థితిలో, HRESULT ("ఫలితం హ్యాండిల్") అర్థం చేసుకోవడానికి, మీరు మరింత లోతుగా పరిశోధించాలి డాక్యుమెంటేషన్ డెవలపర్‌ల కోసం. సాధారణ జీవితంలో, దీన్ని చేయమని నేను మీకు సలహా ఇవ్వను, కానీ మీరు అకస్మాత్తుగా గోడకు వ్యతిరేకంగా నొక్కితే లేదా ఆసక్తిగా ఉంటే, ఇప్పుడు ఏమి చేయాలో మీకు తెలుసు.

కానీ మైక్రోసాఫ్ట్‌లోని కామ్రేడ్‌లు మాపై కొంచెం జాలిపడి ప్రపంచానికి ఒక ప్రయోజనాన్ని చూపించారు ERR. ఇది Googleని ఉపయోగించకుండానే ఎర్రర్ కోడ్‌లను మనుషులలోకి అనువదించగల కన్సోల్ ఆనందం యొక్క చిన్న భాగం. ఇది ఇలా పనిచేస్తుంది.

C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"

ఒక చట్టబద్ధమైన ప్రశ్న తలెత్తుతుంది: మేము వెంటనే లాగ్‌లకు డిక్రిప్షన్‌ను ఎందుకు వ్రాయకూడదు, కానీ ఈ మర్మమైన కోడ్‌లను ఎందుకు వదిలివేయాలి? సమాధానం థర్డ్-పార్టీ అప్లికేషన్‌లలో ఉంది. మీరు మీరే కొన్ని WinAPI కాల్‌ని లాగినప్పుడు, దాని ప్రతిస్పందనను అర్థంచేసుకోవడం కష్టం కాదు, ఎందుకంటే దీని కోసం ప్రత్యేక WinAPI కాల్ కూడా ఉంది. కానీ ఇప్పటికే చెప్పినట్లుగా, ప్రతిస్పందనలలో మాత్రమే మనకు వచ్చే ప్రతిదీ మన లాగ్‌లలోకి వస్తుంది. మరియు ఇక్కడ, దానిని డీక్రిప్ట్ చేయడానికి, ఈ స్పృహ ప్రవాహాన్ని నిరంతరం పర్యవేక్షించవలసి ఉంటుంది, దాని నుండి విండోస్ లోపాలతో ముక్కలను తీసి, వాటిని డీక్రిప్ట్ చేసి, వాటిని తిరిగి అతికించండి. నిజాయితీగా ఉండనివ్వండి, అత్యంత ఉత్తేజకరమైన కార్యకలాపం కాదు.

విండోస్ ఫైల్ మేనేజ్‌మెంట్ API ఫైల్‌లతో పనిచేసేటప్పుడు సాధ్యమయ్యే ప్రతి విధంగా ఉపయోగించబడుతుంది. ఫైళ్లను సృష్టించడం, తొలగించడం, రాయడం కోసం తెరవడం, లక్షణాలతో పని చేయడం మొదలైనవి.

పైన పేర్కొన్న పవర్‌షెల్ డైరెక్ట్ హైపర్-V ప్రపంచంలోని VIX API యొక్క అనలాగ్‌గా. దురదృష్టవశాత్తు, చాలా సరళమైనది కాదు: కార్యాచరణపై చాలా పరిమితులు, ఇది హోస్ట్ యొక్క ప్రతి సంస్కరణతో పని చేయదు మరియు అన్ని అతిథులతో కాదు.

సిపిపి (రిమోట్ ప్రొసీజర్ కాల్) RPC-సంబంధిత ఎర్రర్‌లను చూడని ఒక్క వ్యక్తి కూడా WIndowsతో పనిచేసినట్లు నేను అనుకోను. జనాదరణ పొందిన అపోహ ఉన్నప్పటికీ, ఇది ఒకే ప్రోటోకాల్ కాదు, అనేక పారామితులను సంతృప్తిపరిచే ఏదైనా క్లయింట్-సర్వర్ ప్రోటోకాల్. అయినప్పటికీ, మా లాగ్‌లలో RPC లోపం ఉంటే, 90% సమయం అది DCOM (డిస్ట్రిబ్యూటెడ్ కాంపోనెంట్ ఆబ్జెక్ట్ మోడల్)లో భాగమైన Microsoft RPC నుండి ఎర్రర్ అవుతుంది. మీరు నెట్‌లో ఈ అంశంపై పెద్ద మొత్తంలో డాక్యుమెంటేషన్‌ను కనుగొనవచ్చు, కానీ దానిలో సింహభాగం చాలా పాతది. కానీ అంశాన్ని అధ్యయనం చేయాలనే తీవ్రమైన కోరిక ఉంటే, నేను కథనాలను సిఫారసు చేయగలను RPC అంటే ఏమిటి?, ఎలా RPC వర్క్స్ మరియు పొడవైన జాబితా RPC లోపాలు.

మా లాగ్‌లలో RPC లోపాల యొక్క ప్రధాన కారణాలు VBR భాగాల మధ్య కమ్యూనికేట్ చేయడానికి విఫలమైన ప్రయత్నాలు (సర్వర్ > ప్రాక్సీ, ఉదాహరణకు) మరియు చాలా తరచుగా కమ్యూనికేషన్ సమస్యల కారణంగా.

అన్ని టాప్‌లలో అగ్రస్థానం లోపం RPC సర్వర్ అందుబాటులో లేదు (1722). సరళంగా చెప్పాలంటే, క్లయింట్ సర్వర్‌తో కనెక్షన్‌ని ఏర్పాటు చేయలేకపోయింది. ఎలా మరియు ఎందుకు - ఏ ఒక్క సమాధానం లేదు, కానీ సాధారణంగా ఇది ప్రామాణీకరణతో లేదా పోర్ట్ 135కి నెట్‌వర్క్ యాక్సెస్‌తో సమస్యగా ఉంటుంది. డైనమిక్ పోర్ట్ అసైన్‌మెంట్‌తో కూడిన ఇన్‌ఫ్రాస్ట్రక్చర్‌లకు రెండోది విలక్షణమైనది. ఈ అంశంపై, కూడా ఉంది ప్రత్యేక HF. మరియు మైక్రోసాఫ్ట్ ఉంది భారీ గైడ్ వైఫల్యానికి కారణాన్ని కనుగొనడానికి.

రెండవ అత్యంత జనాదరణ పొందిన లోపం: ఎండ్‌పాయింట్ మ్యాపర్ (1753) నుండి మరిన్ని ఎండ్ పాయింట్‌లు అందుబాటులో లేవు. RPC క్లయింట్ లేదా సర్వర్ పోర్ట్‌ను కేటాయించడంలో విఫలమైంది. సాధారణంగా సర్వర్ (మా సందర్భంలో, అతిథి యంత్రం) ముగిసిన ఇరుకైన పరిధి నుండి పోర్ట్‌లను డైనమిక్‌గా కేటాయించడానికి కాన్ఫిగర్ చేయబడినప్పుడు సంభవిస్తుంది. మరియు మీరు క్లయింట్ వైపు నుండి (మా విషయంలో, VBR సర్వర్) లాగిన్ అయితే, దీని అర్థం మా VeeamVssAgent ప్రారంభించబడలేదని లేదా RPC ఇంటర్‌ఫేస్‌గా నమోదు చేయబడలేదని అర్థం. ఈ అంశంపై కూడా ఉంది ప్రత్యేక HF.

సరే, టాప్ 3 RPC ఎర్రర్‌లను పూర్తి చేయడానికి, RPC ఫంక్షన్ కాల్ విఫలమైందని గుర్తుంచుకోండి (1726). కనెక్షన్ ఏర్పాటు చేయబడితే కనిపిస్తుంది, కానీ RPC అభ్యర్థనలు ప్రాసెస్ చేయబడవు. ఉదాహరణకు, మేము VSS స్థితి గురించి సమాచారాన్ని అభ్యర్థిస్తాము (అకస్మాత్తుగా ప్రస్తుతం అక్కడ షాడో గని తయారు చేయబడుతోంది మరియు మేము ఎక్కడానికి ప్రయత్నిస్తున్నాము), మరియు మాకు ప్రతిస్పందనగా, నిశ్శబ్దం మరియు విస్మరించండి.

విండోస్ టేప్ బ్యాకప్ API టేప్ లైబ్రరీలు లేదా డ్రైవ్‌లతో పని చేయడం అవసరం. నేను ప్రారంభంలో చెప్పినట్లుగా: మా స్వంత డ్రైవర్లను వ్రాసి, ప్రతి పరికరం యొక్క మద్దతుతో బాధపడటంలో మాకు ఎటువంటి ఆనందం లేదు. అందువల్ల, vim దాని స్వంత డ్రైవర్లను కలిగి లేరు. అన్ని ప్రామాణిక API ద్వారా, హార్డ్‌వేర్ విక్రేతల ద్వారానే మద్దతు అమలు చేయబడుతుంది. చాలా లాజికల్, సరియైనదా?

SMB / CIFS CIFS (కామన్ ఇంటర్నెట్ ఫైల్ సిస్టమ్) అనేది కేవలం SMB (సర్వర్ మెసేజ్ బ్లాక్) యొక్క ప్రైవేట్ వెర్షన్ అని అందరికీ గుర్తుండకపోయినా, అలవాటు లేకుండా, ప్రతి ఒక్కరూ వాటిని పక్కపక్కనే వ్రాస్తారు. కాబట్టి ఈ భావనలను సాధారణీకరించడంలో తప్పు లేదు. Samba ఇప్పటికే LinuxUnix ఇంప్లిమెంటేషన్‌గా ఉంది మరియు దాని స్వంత ప్రత్యేకతలను కలిగి ఉంది, కానీ నేను పక్కకు తప్పుకుంటాను. ఇక్కడ ముఖ్యమైనది ఏమిటంటే: UNC పాత్ (సర్వర్ డైరెక్టరీ)కి ఏదైనా వ్రాయమని Veeam అడిగినప్పుడు, సర్వర్ బంతికి వ్రాయడానికి mup మరియు mrxsmbతో సహా ఫైల్ సిస్టమ్ డ్రైవర్‌ల క్రమానుగతాన్ని ఉపయోగిస్తుంది. దీని ప్రకారం, ఈ డ్రైవర్లు లోపాలను కూడా సృష్టిస్తాయి.

లేకుండా చేయలేము Winsock API. నెట్‌వర్క్ ద్వారా ఏదైనా చేయవలసి వస్తే, VBR Windows Socket API ద్వారా పని చేస్తుంది, దీనిని విన్‌సాక్ అని పిలుస్తారు. కాబట్టి మనం లాగ్‌లో IP:Port యొక్క సమూహాన్ని చూస్తే, ఇది అంతే. అధికారిక డాక్యుమెంటేషన్‌లో సాధ్యమయ్యే మంచి జాబితా ఉంది లోపాలు.

పైన పేర్కొన్న WMI (Windows Management Instrumentation) అనేది Windows ప్రపంచంలోని ప్రతిదానిని మరియు ప్రతి ఒక్కరినీ నిర్వహించడానికి ఒక రకమైన సర్వశక్తిమంతమైన API. ఉదాహరణకు, హైపర్-వితో పని చేస్తున్నప్పుడు, హోస్ట్‌కు దాదాపు అన్ని అభ్యర్థనలు దాని ద్వారా వెళ్తాయి. ఒక్క మాటలో చెప్పాలంటే, విషయం పూర్తిగా పూడ్చలేనిది మరియు దాని సామర్థ్యాలలో చాలా శక్తివంతమైనది. ఎక్కడ మరియు ఏది విచ్ఛిన్నమైందో కనుగొనడంలో సహాయపడే ప్రయత్నంలో, అంతర్నిర్మిత WBEMtest.exe సాధనం చాలా సహాయపడుతుంది.

మరియు జాబితాలో చివరిది, కానీ తక్కువ ప్రాముఖ్యత లేదు - విఎస్ఎస్ (వాల్యూమ్ షాడో స్టోరేజ్). టాపిక్ దానిపై చాలా డాక్యుమెంటేషన్ వ్రాయబడినంత తరగని మరియు రహస్యమైనది. షాడో కాపీ అనేది ఒక ప్రత్యేక రకం స్నాప్‌షాట్‌గా చాలా సరళంగా అర్థం చేసుకోవచ్చు, సారాంశంలో ఇది. అతనికి ధన్యవాదాలు, మీరు VMwareలో అనువర్తన-స్థిరమైన బ్యాకప్‌లను మరియు హైపర్-Vలో దాదాపు ప్రతిదీ చేయవచ్చు. నేను VSSపై కొంత స్క్వీజ్‌తో ప్రత్యేక కథనాన్ని రూపొందించాలని ప్లాన్ చేస్తున్నాను, కానీ ప్రస్తుతానికి మీరు చదవడానికి ప్రయత్నించవచ్చు ఈ వివరణ. జాగ్రత్తగా ఉండండి, ఎందుకంటే. ఒక ఫ్లాష్‌లో VSSని అర్థం చేసుకోవడానికి ప్రయత్నించడం మెదడు గాయానికి దారితీస్తుంది.

దీనిపై, బహుశా, మనం ఆపవచ్చు. పూర్తి చేసిన ప్రాథమిక విషయాలను వివరించే పనిని నేను పరిగణించాను, కాబట్టి తరువాతి అధ్యాయంలో మేము ఇప్పటికే లాగ్‌లను పరిశీలిస్తాము. కానీ మీకు ఏవైనా ప్రశ్నలు ఉంటే, వాటిని వ్యాఖ్యలలో అడగడానికి సంకోచించకండి.

మూలం: www.habr.com