Weird random problems when using aspi with delphi

CD, DVD and (Ultra HD) Blu-ray Writers
#1

Have anyone experienced random problems with delphi programs using the aspi version that comes with windows 95/98? I’m having such problems… it gives me access violations on random parts of code… and for eg. if I change something on code the access violation is raised in another place of code… very odd… If I update aspi there are no problems but for eg. with programs made with C++ Builder I get no problems even with original w98 aspi…

for eg. try to compile this:

function SendASPI32Command(LPSRB : pointer) : DWORD; cdecl; external 'WNASPI32'; 

type SRB_GetDiskInfo = packed record 
        SRB_Cmd, 
        SRB_Status, 
        SRB_HaId, 
        SRB_Flags : BYTE; 
        SRB_Hdr_Rsvd : DWORD; 
        SRB_Target, 
        SRB_Lun, 
        SRB_DriveFlags, 
        SRB_Int13HDriveInfo, 
        SRB_Heads, 
        SRB_Sectors : BYTE; 
        SRB_Rsvd1 : array [0..9] of byte; 
     end; 

function getdriveletter(ha, id, lun : byte) : string; 
var srb : SRB_GetDiskInfo; 
begin 
  FillChar(srb, sizeof(srb), 0); 
  srb.SRB_Cmd := 6; //SC_GET_DISK_INFO 
  srb.SRB_HaId := ha; 
  srb.SRB_Target := id; 
  srb.SRB_Lun := lun; 
  SendASPI32Command(@srb); 
  result := chr(ord('A') + (srb.SRB_Int13HDriveInfo - 1));
end; 

procedure TForm1.FormCreate(Sender: TObject); 
begin 
  showmessage(getdriveletter(0,0,0)); 
end;

then try to run it in win95 or 98 with original aspi and you will get access violation…

then try to put all code in FormCreate instead of use getdriveletter function… and it works fine… very odd problem… I tried different versions of delphi and happens with all, I tried to make a similar thing with BC++ and works fine… any clue?

#2

I think that I have found the problem, these random problems only happen when using srb as a declared local var, if you use a global var or allocate it with getmem is works fine.

#3

I tried to look into the problem too, but couldn’t find a thing. You’re right it is to do with the local var. My tool uses delphi too but most of the variables that are associated with ASPI are globals.

#4

Sorry to bring up such an old topic but I think this information may be useful for someone else…

I didn’t touched all this for years now, however the other day when trying to organize some old files/folders in my hdd’s I did found some code I did wrote using ASPI a few years ago… I remembered “why the hell I did never found the reason for that old odd issue with original ASPI version that ships with Windows 95 and 98?”… it is not important anymore nowadays for sure but damn… still, why? :slight_smile: Well, I did picked an Windows 98 VM and did a few tests on it, and I finally found what was happening.

It’s not related to local/global variables at all, and it doesn’t happen only on Delphi compiled app’s. My assumptions on my posts above were totally wrong.

The real problem is that to work with that old ASPI version that comes with Windows 95/98 (maybe ME?), we must always allocate at least 36 bytes for SRB, even for small SRB structures like SRB_GDEVBlock, SRB_GetDiskInfo, SRB_RescanPort, failing to do this we will end with corruption in our app as ASPI (this version only) will always write 4 bytes with 0x00 at bytes 32 to 35 offset from the SRB pointer we passed to SendASPI32Command()… if we allocated less than 36 bytes then these 4 0x00’s will logically overwrite something else in our app… this may be noticeable easily or not depending on the bytes it will overwrite, it may silently corrupt the value of some other variable in our app or just cause some access violation as the ones I described on my post above, the behavior will depend on the rest of code in our app, etc…

Why this? No idea… but it’s true, and it’s not hard to test it, just code a small sample like the one on my 1st post, allocate +12 bytes (total 36) for the structure, then fill all 12 bytes with 0xff before calling SendASPI32Command(), then recheck these 12 bytes after calling it and you will find last 4 bytes will be 0x00…

I did tested it by compiling such test code on both Delphi and Borland C Builder and reproduced the same exact problem on both, that’s why I said above on this post it is not a problem with Delphi compiled apps at all.

Ok I know probably no one want’s to code anything to run on Windows 95/98 nowadays, but I thought I should share the info and correct my bad assumptions :slight_smile: