تعطل تطبيق C ++ منخفض المستوى على Windows Vista/7 ما لم يتم تشغيله في وضع توافق XP

Question

لدي مستوى منخفض (مثل هل حقا من المستوى المنخفض ، إنه في الأساس جميع مكالمات IOCTL والعديد من المكالمات لتعداد واجهات برمجة التطبيقات) التي تتعطل بشكل متقطع على Windows Vista/7 على آلات العملاء. لسوء الحظ ، لم أتمكن من شراء أي مقالب تحطم ، لكن مستخدمًا مفيدًا لم يذكر أن تشغيل البرنامج في وضع توافق XP يحل المشكلة.

يتم إطلاق التطبيق دائمًا بحقوق المسؤول الكاملة (يتم إطلاقه من برنامج آخر يتطلب إذن المسؤول) بحيث لا يمثل مشكلة UAC. لا أستخدم أي واجهات برمجة تطبيقات تم إهمالها وأنا لا أعتمد على أي اختراقات تسجيل ، وما إلى ذلك. أنا فقط أصدر مكالمات لتعداد الأقراص ، ثم باستخدام أوامر IOCTL للحصول على بعض المعلومات ذات المستوى المنخفض حول جميع الأجهزة المرفقة.

ماذا يحدث في وضع توافق XP؟ ما الذي يقوم به Windows في طلبي أو صندوق الرمل بطريقة أخرى يمنعه من الانهيار على Vista/7؟ كنت قد اشتبهت في الأصل في فساد الكومة (على الرغم من أنني سحبت شعري خارج محاولة التكرار أو تعقب المشكلة) قبل أن يتم إخباره بأنه يعمل بشكل جيد في وضع توافق XP.

هل يمكن لأي شخص أن يقترح أي مشكلات محتملة يتم تجنبها في وضع Compat XP الذي يجب أن أبحث عنه لمحاولة معالجة هذه المشكلة؟ شكرًا!

تعديل:

شيء آخر ربما يكون من المهم للغاية ذكره: أنا أتصل بوظائف DDK/kernel من مساحة المستخدمين من أجل الحصول على بعض الميزات التي لا تتعرض عبر واجهة برمجة تطبيقات Win32.

أنا أستخدم Zwreadfile و Zwcreatefile و ZwwriteFile و Rtlinitunicodestring و ZwqueryvolumeInformationFile و Zwdeviceiocontrolfile و ZwsetInformationFile و Zwclose.

تتضمن IOCTLS التي أتصل بها IOCTL_DISK_GET_PARTITION_INFO_EX ، IOCTL_STORAGE_GET_DEVICE_NUMBER ، IOCTL_DISK_GET_LENGTE_INFO ، و IOCTL_DISK_DRIVE_LAYOUT_EX.

Answer 1

هذا أمر غريب للغاية ، لكنني كنت أتصل بـ zwqueryvolumeInformationFile مع تعيين fsinformationClass إلى filefsvolumeInformation.

لقد مررت في مخزن مؤقت لـ file_fs_volume_information أولاً ، ثم تم تخصيصه بشكل عام ، ثم تم تخصيصه بشكل عام (sizeof(FILE_FS_VOLUME_INFORMATION) + sizeof(TCHAR)*FILE_FS_VOLUME_INFORMATION->VolumeLabelLength).

ثم اتصلتFILE_FS_VOLUME_INFORMATION->VolumeLabel[FILE_FS_VOLUME_INFORMATION->VolumeLabelLength/2] = _T('\0'); و فقط على بعض الآلات هذا من شأنه أن يؤدي إلى فساد الذاكرة.

بغض النظر عن حجم التخصيص الشامل (حتى حاول تخصيص 256 Chars Extra!) ، فإن هذا سيؤدي بشكل موثوق إلى فساد الكومة حتى في عند استخدام vector<unsigned char> كمؤسس file_fs_volume_information.

يبدو أن النواة تضع نوعًا من حماية الكتابة على المخزن المؤقت بطريقة ما مما أدى إلى الفساد بغض النظر عن الحجم. نسخ أول بايتات الطول إلى المخزن المؤقت الثاني ، من ثم بعد الانتهاء _T('\0') حل المشكلة. لست متأكدًا كيف/لماذا كان Windows يصنع المخزن المؤقت أنا تم تخصيصها وتمريرها كمعلمة قراء أو إذا كانت تخزين بعد هيكل file_fs_volume_information (الذي ينبغي انتهى مع صفيف الأحرف!) ، ولكن ببساطة عدم تعديل أي بيانات في المخزن المؤقت الذي مررت به فعل الخدعة .... وهو أمر مجنون لأنه يحدث فقط (باستمرار و 100 ٪ قابلة للتكرار) على أجهزة معينة.

على أي حال: حل المشكلة *phew *!

Answer 2

كانت هناك العديد من التغييرات في برنامج التشغيل منخفض المستوى من XP إلى Vista. أظن أنك تستخدم IOCTL تتأثر به.