Low-Level-C ++ App-Abstürze unter Windows Vista / 7 Sofern Run in XP Kompatibilitätsmodus

Question

Ich habe ein Low-Level (wie wirklich Low-Level, es ist im Grunde alle IOCTL Anrufe und mehrere Anrufe Enumeration APIs), die sporadisch auf Windows Vista / 7 auf Kunden Maschinen abstürzt. Leider habe ich nicht in der Lage gewesen, kein Crash-Dumps zu beschaffen, aber ein hilfreicher Benutzer erwähnt hat, dass das Programm im XP-Kompatibilitätsmodus ausgeführt wird das Problem gelöst.

Die Anwendung wird immer mit vollem Admin-Rechten gestartet (es von einem anderen Programm gestartet ist, die Admin-Berechtigung erforderlich), so dass es kein Problem ist UAC. Ich habe keine veralteten APIs verwenden, und ich bin auf alle Registry-Hacks nicht verlassen, etc. Ich bin nur Anrufe aufzuzählen Platten Ausgabe, befiehlt dann mit IOCTL etwas mehr Low-Level-Informationen über alle angeschlossenen Geräte zu erhalten.

Was passiert im XP-Kompatibilitätsmodus? Was funktioniert Windows inject in meine Anwendung oder anderweitig Sandbox mit verhindert, dass von ihrem Absturz auf Vista / 7? Ich hatte ursprünglich Heapbeschädigung Verdacht (obwohl ich mir die Haare aus dem Versuch gezogen haben zu replizieren oder das Problem auf die Spur), bevor gesagt, dass es gut in XP-Kompatibilitätsmodus ausgeführt wird.

Kann jemand alle möglichen Probleme vorschlagen, die in XP Compat Modus vermieden werden würde, dass ich in aussehen sollte, um zu versuchen, dieses Problem zu lösen? Dank!

EDIT:

Eine weitere Sache, die wahrscheinlich sehr wichtig ist, zu erwähnen. Ich rufe DDK / Kernel-Funktionen von Anwenderseite, um zu bestimmten Funktionen, die nicht über das WIN32 API ausgesetzt zu bekommen

Ich bin mit ZwReadFile, ZwCreateFile, ZwWriteFile, RtlInitUnicodeString, ZwQueryVolumeInformationFile, ZwDeviceIoControlFile, ZwSetInformationFile, ZwClose.

Die IOCTLs Ich rufe gehören IOCTL_DISK_GET_PARTITION_INFO_EX, IOCTL_STORAGE_GET_DEVICE_NUMBER, IOCTL_DISK_GET_LENGTH_INFO und IOCTL_DISK_GET_DRIVE_LAYOUT_EX.

Answer 1

Das ist sehr seltsam, aber ich rufe ZwQueryVolumeInformationFile mit FsInformationClass Satz FileFsVolumeInformation.

ich in einem Puffer von FILE_FS_VOLUME_INFORMATION vergangen war zunächst normal zugewiesen, dann (sizeof(FILE_FS_VOLUME_INFORMATION) + sizeof(TCHAR)*FILE_FS_VOLUME_INFORMATION->VolumeLabelLength) lasteten.

Dann rief ich FILE_FS_VOLUME_INFORMATION->VolumeLabel[FILE_FS_VOLUME_INFORMATION->VolumeLabelLength/2] = _T('\0'); und nur auf einigen Maschinen diese in einer Speicherbeschädigung führen würde.

Unabhängig von der Größe der Überzuteilung (sogar versucht, ein volles 256 Zeichen Zuteilung extra!), Dies würde dazu führen, zuverlässig in Heapbeschädigung noch , wenn eine vector<unsigned char> als FILE_FS_VOLUME_INFORMATION Puffer verwendet wird.

Es scheint, dass der Kernel auf den Puffer eine Art von Schreibschutz legt irgendwie, die unabhängig von der Größe der Korruption resultierenden wurde. Kopieren der ersten VolumeLableLength Bytes zu einem zweiten Puffer, und post angemeldete _T('\0') das Problem gelöst. Nicht sicher, wie / warum Windows-bildete den Puffer, dass I zugeordnet und übergeben als Parameter nur lesbar oder , wenn es speicherte nach die FILE_FS_VOLUME_INFORMATION struct (die sollte Ende mit dem Zeichen-Array), aber einfach keine Daten im Puffer zu modifizieren, dass ich bestehen den Trick tat .... was verrückt ist, weil es geschieht nur (konsequent und 100% reproduzierbar ) auf bestimmte Maschinen.

Auf jeden Fall: Problem gelöst * puh *

Answer 2

Es gibt viele Änderungen in dem Low-Level-Fahrer von XP auf Vista gewesen. Ich vermute, dass Sie ein IOCTL verwenden, der davon betroffen ist.