Compiling ACPI v2.0 driver for Windows XP SP3 and Windows 2003 SP2 (x32/x64)

[K4sum1]

I tried acpiSkull2.sys, and it works

Thank you.

Btw which one would be the best to use in general? acpiSkull2.sys or acpiSkullXPSp2bit64.sys?

[K4sum1]

By the way, do you have something similar for 2003 x86?

[Dietmar]

@K4sum1

Here is the same as Skull2 for server 2003 bit32

https://ufile.io/3a7684oj

For XP SP2 bit64 I would use skull2 acpi.sys, because for you it is the one, which matches exact your Bsod.

By the way, what shows the first of the 3 acpi.sys for bit64, where I cancel out (dirty hack) the Bsod 0xA5 (0x03, ...) itself

Dietmar

 

[Dietmar]

Hi,

I make a test with two USB3 sticks:

Kingston Workspace Datatraveler 64 GB

and

Sandisk Extreme Pro USB 3.1 256 GB

 

Both sticks show a transferrate of more than 300 MByte/s and until now I am happy with them.

Because on both sticks are important files from me, today I make a one by one bit copy via WinHex from the whole USB stick each. Both USB sticks have few bytes left free.

And I store this result on a brandnew harddisk WD2003FZEX as*.dat file each.

This 2TB Sata harddisk is manufactured in the end of 2023 in Taiwan, solid as much as possible.

But now comes my bad surprise:

Via Winhex I compare the content of the original USB stick with its *.dat file on this harddisk.

Millions of errors are shown. This I have never seen before.

When I transfer data between two of those harddisks from 2TB of WD,

the error rate is <10^(-14) , means no error(!) in whole 2000 Gigabyte.

Just now I am checking, what is going on.

I copy the *.dat file back to such another, empty brandnew WD harddisk. and compare the result via Winhex of correctness.

Then with with Beyond Compare I check,

if there are really errors in the data, or if the crazy USB3 bus copies the space between datas not correct.

Just now I think, that even expensive USB sticks are bad as much as possible for to store sensitive data

Dietmar

EDIT1: As expected, because of the ultrahigh quality of those harddisks,

not a single error is shown between the *.dat files and their copy to this brandnew harddisk.

EDIT2:

The file compare via Beyond Compare 4 shows for 77 different files (all located on the USB stick)

the message "stream error, cant compare".

So, what does this mean? The error is indeed located on the USB stick, the information cant be read out any longer

from that USB stick.

Winhex shows during copy no error. In my Winhex versionit  is no possibility to check, if a copy has been done successful.

Crazy, those 77 files are gone (no, see Edit3). Some big, some small..

EDIT3: Oh crazy, I check by hand some of the files on the USB stick, that cant be read by Beyond Compare 4.

They work. All is ok with them. So I run another check with Beyond Compare 2. All files are now shown as identic.

What does this mean? The USB stick is not that bad as I thought. Bad is Beyond Compare 4.

Nice works Beyond Compare 2 and it is even much faster.

And: The files are stored on an USB stick, so that Winhex cant read them out one after the other as on a harddisk.

EDIT4: This also means, that you can make with Winhex a correct bit by bit data copy from an whole USB stick.

And restore after also correct all the files from such a *.dat file. But the structure in such a *.dat file from an USB stick is different to the structure for the same files(!) via harddisk.

Would be interesting if somebody here in the forum can put some light on this behavior of an USB stick.

Edited July 19 by Dietmar

[K4sum1]

I have both x86 and x64 working on my E7250

Now I need Broadwell drivers which I can't seem to find. Unable to get iGPU to work under XP.

[reboot12]

@Dietmar

Provide data:

• computer hardware specifications
• what operating system
• what version of acpi.sys
• what version of USB3 drivers

In WinHex do this:

• menu Tools > Disk Tools > Clone Disk... > click HDD icon in Source > Physical Media > USB stick
• click file icon in Destination then name copy.img on WD2003FZEX
  
• from menu Tools > Disk Tools > Open Disk... > Physical Media > USB stick
• from menu Tools > File Tools > Compare... compare file copy.img and opened USB stick
  

[Dietmar]

@reboot12

I am just trying your method for the Kingston USB3 stick.

This operation needs 4 times longer than my method of to copy the USB stick just as a whole block via Winhex.

Do you know, if via your method Winhex makes a check, if the copied data are the same as the original ones?

Because there must be a reason for time delay.

Still the mystery in the behavior of USB3 sticks in my post above stays.

Because there is no error at all after crazy checks, but different structure in the stored data from the USB stick, compared with the structure from a harddisk via Winhex.

 

I use my last acpi.sys from the Ramsey XP SP3

and also the USB3 driver from there (nice for USB3 boot modded driver from @Mov AX, 0xDEAD)

on a Gigabyte z690 UD DDR4 board, 12900k with 32 GB ram.

Before I noticed real errors in any USB3 driver that I tested,

when I copy millions of files one by one from the USB stick to the harddisk.

And this errors happen also under Win10, 64 bit

Dietmar

 

Edited July 20 by Dietmar

[Dietmar]

@reboot12

This is, what ChatGPT tells about the difference of both copy methods via Winhex.

But for me it is still strange: Does it mean, that Winhex copies the Checksum always between the files???

It seems, that Winhex indeed does a check of every sector, that it has been copied correct.

 

But the mystery remains:

The data on an USB3 stick are other stored other (geometrie, sectors???) than on a harddisk

Dietmar

 

Winhex:

Image File (Whole Physical Disk Copy):

Objective: Create a complete copy of the entire disk, including all sectors, both used and unused.

Additional Tasks:

Checksum Calculation: To verify the integrity of the copied data.

File System Metadata Handling: Reading and writing file system metadata to ensure a faithful reproduction of the disk's structure.

"Copy Block" Mode:

Objective: Copy specific blocks or sectors of the disk as specified by the user.

No Additional Tasks:

No Checksum Calculation: Since only specific blocks are copied, there's no need to verify the entire disk's integrity.

Ignoring File System Metadata: Focuses solely on the data within the specified blocks without considering the overall file system structure.

Impacts on Duration:

Image File:

Longer Duration: Due to the comprehensive nature of the task, including checksum calculation and file system metadata handling.

Advantages:

Higher Data Security: The checksum ensures that the data integrity can be verified.

Complete Copy: Includes all data, which is beneficial for forensic analysis and full data recovery.

 

"Copy Block" Mode:

Shorter Duration: Faster as it copies only specified blocks and skips additional tasks.

Advantages:

Efficiency: Suitable for situations where only specific parts of the disk are needed.

In summary, creating an image of the whole physical disk is more thorough and secure but takes longer, while the "copy block" mode is quicker and more efficient for targeted data copying.

4o

Edited July 20 by Dietmar

[reboot12]

@Dietmar

I don't understand what it means to copy the block mode? How do you do it in WinHex ? (give screenshots).

My way is to make an image using the sector-by-sector copy like the DD command in Linux.

[Dietmar]

@reboot12

You can select a block in Winhex, for a given file.

I use this method for the whole USB3 stick. It is ultrafast.

Now I understand what happens:

These raw data via "Block Copy" are exact that one, that stays on the USB3 stick at the moment, when it was copied.

But other than on a harddisk, there is NO one by one LBA adressing to the real Values in an USB3 stick.

The internal logic of the USB3 stick changes this data, as it think, that it is useful, crazy,

for example not to write to the same memory too much,

or to overjump errors

Dietmar

The behavior you observed is due to the fundamental differences in how data is managed on USB3 sticks compared to hard disks. Wear leveling, garbage collection, and ECC on USB sticks introduce complexities that raw block copying cannot handle correctly, leading to discrepancies in bit-by-bit comparisons. However, file-level integrity is maintained through the file system, ensuring that restored files are accurate.

 

Edited July 20 by Dietmar

[reboot12]

11 minutes ago, Dietmar said:

You can select a block in Winhex, for a given file.

Still I don't understand! What block? Show on the screenshot how you do it in WinHex.

[Dietmar]

[reboot12]

Which version WinHex you use? How you open USB stick and how do you mark the block?

OK, I make tests with 1GB USB 2.0 stick on USB 2.0 port - 2 way to make image file - I always use Tools > Open Disk... > Physical Media > USB stick:

• Tools > Disk Tools > Clone Disk... > Destination raw clone.img - creation time 1.5 min
• Ctrl+A to select all data, Edit > Copy Block > Into New File block.img - creation time 1.5 min

Both files have exactly the same size and checksum:

Maybe your USB stick is damaged ?

[Dietmar]

@reboot12

My Winhex is 11.9.

Funny, my old Winhex copies without internal intelligence all, what it is offered, bit by bit

Dietmar

EDIT: Just now, my *.img from the Kongston USB3 stick is ready.

Now, Winhex shows no differences to the USB stick and this *.img.

This means, my version of Winhex copies indeed the actual block of everything correct

and the USB stick is also correct. And this RAW copy is 4 times faster.

Edited July 20 by Dietmar

[reboot12]

36 minutes ago, Dietmar said:

And this RAW copy is 4 times faster.

Hymmmm...

I did the test on ThinkPad X61 with SATA HDD disk in WinXP SP2 64-bit with the original acpi.sys and USB EHCI driver.

Now I'm going to my Intel Gen 8 WinXP SP2 64-bit machine with NVMe disk and modded driver NVMe 6.1.7601.23403, with modified acpi.sys 7777.8 and modded USB XHCI 6.2.9200.22099 driver

I will report after tests.