பதிவுகள் எங்கிருந்து வருகின்றன? வீம் லாக் டைவிங்

பதிவுகள் மூலம் சரிசெய்தல் ... யூகத்தின் கண்கவர் உலகில் மூழ்கித் தொடர்கிறோம். 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 ஐ விட சிறந்தது. Hyper-V இல், இந்த விஷயம் PowerShell Direct என்று அழைக்கப்படுகிறது. ஆனால் அது முன்புதான் இருந்தது

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, நினைவகம் இல்லை. இது ஏன், யாருக்காக செய்யப்பட்டது என்பது இருளில் மூழ்கியிருக்கும் மர்மம். இருப்பினும், பிழைகளின் முழுமையான பட்டியலை இலவசமாகவும் எஸ்எம்எஸ் இல்லாமல் பதிவிறக்கம் செய்யலாம் 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 கோப்புகளுடன் பணிபுரியும் போது சாத்தியமான எல்லா வழிகளிலும் பயன்படுத்தப்படுகிறது. கோப்புகளை உருவாக்குதல், நீக்குதல், எழுதுவதற்குத் திறப்பது, பண்புக்கூறுகளுடன் பணிபுரிதல், மற்றும் பல.

மேலே குறிபிட்டபடி பவர்ஷெல் நேரடி ஹைப்பர்-வி உலகில் VIX API இன் அனலாக். துரதிருஷ்டவசமாக, மிகவும் நெகிழ்வானது அல்ல: செயல்பாட்டில் நிறைய கட்டுப்பாடுகள், இது ஹோஸ்டின் ஒவ்வொரு பதிப்பிலும் வேலை செய்யாது மற்றும் அனைத்து விருந்தினர்களுடனும் அல்ல.

RPC ஐ (Remote Procedure Call) 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. நெட்வொர்க்கில் ஏதாவது செய்ய வேண்டியிருந்தால், விபிஆர் விண்டோஸ் சாக்கெட் ஏபிஐ மூலம் செயல்படுகிறது, இது பிரபலமாக வின்சாக் என்று அழைக்கப்படுகிறது. எனவே, பதிவில் IP:Port இன் ஒரு தொகுப்பைக் கண்டால், இதுதான். அதிகாரப்பூர்வ ஆவணங்கள் சாத்தியமானவற்றின் நல்ல பட்டியலைக் கொண்டுள்ளன பிழைகள்.

மேலே குறிபிட்டபடி WMI (Windows Management Instrumentation) என்பது Windows உலகில் உள்ள அனைத்தையும் மற்றும் அனைவரையும் நிர்வகிப்பதற்கான ஒரு வகையான சர்வ வல்லமை வாய்ந்த API ஆகும். எடுத்துக்காட்டாக, ஹைப்பர்-வி உடன் பணிபுரியும் போது, ​​ஹோஸ்டுக்கான கிட்டத்தட்ட அனைத்து கோரிக்கைகளும் அதன் மூலம் செல்கின்றன. ஒரு வார்த்தையில், விஷயம் முற்றிலும் ஈடுசெய்ய முடியாதது மற்றும் அதன் திறன்களில் மிகவும் சக்தி வாய்ந்தது. எங்கு, என்ன உடைந்துள்ளது என்பதைக் கண்டறிய உதவும் முயற்சியில், உள்ளமைக்கப்பட்ட WBEMtest.exe கருவி பெரிதும் உதவுகிறது.

பட்டியலில் கடைசியாக, ஆனால் எந்த வகையிலும் முக்கியத்துவம் இல்லை - வீ (தொகுதி நிழல் சேமிப்பு). பல ஆவணங்கள் எழுதப்பட்டிருப்பதால் தலைப்பு விவரிக்க முடியாதது மற்றும் மர்மமானது. நிழல் நகல் என்பது ஒரு சிறப்பு வகை ஸ்னாப்ஷாட்டாக மிகவும் எளிமையாக புரிந்து கொள்ளப்படுகிறது, இது சாராம்சத்தில் உள்ளது. அவருக்கு நன்றி, நீங்கள் VMware இல் பயன்பாட்டு-நிலையான காப்புப்பிரதிகளை உருவாக்கலாம், மேலும் ஹைப்பர்-V இல் கிட்டத்தட்ட அனைத்தையும் செய்யலாம். நான் VSS இல் ஒரு தனி கட்டுரையை உருவாக்க திட்டமிட்டுள்ளேன், ஆனால் இப்போது நீங்கள் படிக்க முயற்சி செய்யலாம் இந்த விளக்கம். கவனமாக இருங்கள், ஏனென்றால். ஒரு ஃபிளாஷ் நேரத்தில் VSS ஐப் புரிந்து கொள்ள முயற்சிப்பது மூளைக் காயத்திற்கு வழிவகுக்கும்.

இதைப் பற்றி, ஒருவேளை, நாம் நிறுத்தலாம். முடிக்கப்பட்ட மிக அடிப்படையான விஷயங்களை விளக்கும் பணியை நான் கருதுகிறேன், எனவே அடுத்த அத்தியாயத்தில் ஏற்கனவே பதிவுகளைப் பார்ப்போம். ஆனால் உங்களிடம் ஏதேனும் கேள்விகள் இருந்தால், கருத்துகளில் அவர்களிடம் கேளுங்கள்.

ஆதாரம்: www.habr.com