**Summary:**
After upgrading from WinBatch 2024A to WinBatch 2025A, an HTTP download script that previously worked without issues now fails with the error "3023: BinaryData: Invalid Binary Data handle passed." The error occurs during a `DllCall` to `InternetReadFile` in the `wininet.dll` library, specifically on line 97 of the script in the `procHttpDownload` subroutine.
**Details:**
- **Script Context:** The script (`udflib.httpdownload.wbt`) is an HTTP download utility that uses `wininet.dll` to download files via HTTP, displaying a progress dialog. It relies heavily on `DllCall` to interact with `wininet.dll` functions (`InternetOpenA`, `InternetConnectA`, `HttpOpenRequestA`, `HttpSendRequestA`, `InternetReadFile`, etc.) and manages binary buffers using `BinaryAlloc`, `BinaryEodSet`, and `BinaryPoke4`.
- **Error Specifics:** The error occurs in the following line:
r = DllCall(wininet, long:"InternetReadFile", long:openreqhandle, lpbinary:databuf, long:btoread, lpbinary:breadbuf)
- `databuf` is allocated with `BinaryAlloc(204800)` (a 200KB buffer).
- `breadbuf` is allocated with `BinaryAlloc(4)` to store the number of bytes read.
- Both buffers are initialized with `BinaryEodSet` and `BinaryPoke4` to ensure proper setup.
- **Behavior Difference:**
- In WinBatch 2024A, the script executes without issues and successfully downloads files.
- In WinBatch 2025A, the script fails with the "3023: Invalid Binary Data handle passed" error during the `InternetReadFile` call.
- **Troubleshooting Attempted:**
1. Reduced the buffer size (`btoread`) from 204800 bytes to 4096 bytes to rule out memory allocation issues.
2. Added additional error checking for `openreqhandle` to ensure the HTTP request handle is valid before the `DllCall`.
3. Verified that binary buffers (`databuf`, `breadbuf`) are properly allocated and initialized using `BinaryEodSet` and `BinaryPoke4`.
4. Added debug output to confirm buffer handles and request handles are non-zero before the `DllCall`.
5. Ensured proper cleanup of handles and memory in the script to avoid resource leaks.
Despite these efforts, the error persists in WinBatch 2025A.
- **Workaround:** Rolling back to WinBatch 2024A resolves the issue, and the script works as expected.
**Suspected Cause:**
The issue appears to be related to a change in WinBatch 2025A's handling of binary data (`lpbinary` parameters) in `DllCall` or stricter validation of binary buffer handles. It's possible that `BinaryAlloc`, `BinaryEodSet`, or the `DllCall` interface with `wininet.dll` behaves differently in the newer version, causing the `InternetReadFile` call to reject the binary buffers as invalid.
**Request:**
Could you please investigate the changes between WinBatch 2024A and 2025A that might affect `DllCall` behavior, binary buffer management (`BinaryAlloc`, `lpbinary` parameters), or interactions with `wininet.dll`? Additionally, any guidance on modifying the script to work with WinBatch 2025A would be greatly appreciated.
**Environment:**
- WinBatch Version: 2025A (originally 2024A before upgrade)
- WIL Version: 6.25aya
- Operating System Tested: Windows 8, Windows 10 or 11
- Script File: `udflib.httpdownload.wbt`
**Attachments:**
- Screenshot of the error message . https://prnt.sc/Jxv0GUQ6sH_o
- The full script (`udflib.httpdownload.wbt`) can be provided if needed for further analysis, but the Script is based on Winbatch Techsupport Article:
;https://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/UDF~-~UDS~Library/Web~UDFs+HTTP~Download~UDFs.txt
and
;HTTPDownload 1.4
; https://techsupt.winbatch.com/webcgi/webb(https://prnt.sc/GUiTk1qNUL0Z)atch.exe?techsupt/nftechsupt.web+WIL~Extenders/WinInet+HTTPDownload~1.4.txt
(https://prnt.sc/Jxv0GUQ6sH_o)
There have been no changes to 2025A that would cause your problem. Neither the binary functions nor the DllCall functions have changed.
Thank you for your prompt response and for confirming that there have been no changes to the binary functions or DllCall functions in WinBatch 2025A that would cause this issue. However, I'd like to emphasize that no changes have been made to the script either. When I roll back to WinBatch 2024A, the script executes perfectly without any errors. Upon upgrading to WinBatch 2025A, the error "3023: BinaryData: Invalid Binary Data handle passed" consistently occurs during the DllCall to InternetReadFile in wininet.dll, and I have been unable to resolve it despite extensive troubleshooting.
Could there have been changes in the WinBatch 2025A runtime environment (e.g., memory management, stack handling, or interaction with the Windows API) that might indirectly affect how DllCall or binary buffers are processed? For example, if 2025A uses a different memory allocation strategy or has stricter validation for handles passed to DllCall, this might cause InternetReadFile to fail in a way that 2024A did not.
Is there a way for WinBatch to provide more additional detail debug logs about the DllCall operation, specifically what causes the "invalid binary data handle" error? For example, logging the state of the binary buffers (databuf, breadbuf) and the openreqhandle just before the DllCall might help identify the issue.
I have 2025A. Be happy to test your script. You could compile a test fileread and share it on Google Drive.
Quote from: usheretov on April 05, 2025, 10:24:32 PMCould there have been changes in the WinBatch 2025A runtime environment (e.g., memory management, stack handling, or interaction with the Windows API) that might indirectly affect how DllCall or binary buffers are processed? For example, if 2025A uses a different memory allocation strategy or has stricter validation for handles passed to DllCall, this might cause InternetReadFile to fail in a way that 2024A did not.
There have not been any changes like the ones you suggest. You can view the changes by looking at the "List of Fixes and Improvements.txt" file. Every change is documented in that file.
Quote from: spl on April 06, 2025, 04:02:47 AMI have 2025A. Be happy to test your script. You could compile a test fileread and share it on Google Drive.
Here is a link - you can download and extract to C:\TEST_WEB and run TEST_WEB.wbt = works in 2024A
https://u.pcloud.link/publink/show?code=XZ1qyY5ZOa6NN6R0fCyEtiPyfOgPXhDLbLyX
Your script's logic has a flaw. The buffer is freed in the "FinishDownload" subroutine before the last DllCall to call the "InternetReadFile" function. The dialog's timer is firing after the buffer is freed, but before the dialog can terminate.
Thank you for identifying the logic flaw in my script (udflib.httpdownload.wbt) where the buffer is freed in FinishDownload before the last DllCall to InternetReadFile, causing the 3023: Invalid Binary Data handle passed error due to the dialog timer firing. I'll test the fix (disabling the timer before cleanup) tomorrow in WinBatch 2025A.
However, your response didn't confirm if you tested this in 2024A or 2025A, or if the fix resolves the issue in 2025A. If this fix works, does it confirm that WinBatch 2025A has stricter, undocumented handle validation measures compared to 2024A? My script worked in 2024A, and I'm concerned that these changes weren't documented initially, despite my early reports of the issue.
No, it does not confirm anything like that. Windows message timers have a granularity of approximately .02 seconds. When the timer fires within that range is at the mercy of the OS. There were no undocumented changes. Like I previously mentioned, every change is documented in the file. Note that we use a source code management system that goes back over 20 years. It is easy to determine any and all changes, including the correction of misspellings in the internal code comments (another story...)
If your script had been written correctly, then you wouldn't need to worry about it. All I did was add this line
if IsDefined(DialogHandle_Http) then DialogProcOptions(DialogHandle_HttpDownload, DIALOG_TIMERTICK, 0)
as the first line in the "FinishDownload" subroutine. Canceling timers is just good programming practice when dealing with code dependent on Windows message loop timers because of timer granularity.
The "if IsDefined(DialogHandle_Http) then" part is likely not necessary since the subroutine is only called from within the UDP callback.
Quote from: usheretov on April 07, 2025, 07:02:33 AMQuote from: spl on April 06, 2025, 04:02:47 AMI have 2025A. Be happy to test your script. You could compile a test fileread and share it on Google Drive.
Here is a link - you can download and extract to C:\TEST_WEB and run TEST_WEB.wbt = works in 2024A
https://u.pcloud.link/publink/show?code=XZ1qyY5ZOa6NN6R0fCyEtiPyfOgPXhDLbLyX
I added Tony's line and ran in 2025A, but got the same error you initially reported. I don't have 2024A available as I don't normally keep older copies anymore.
Did you add the line "DialogProcOptions(DialogHandle_HttpDownload, DIALOG_TIMERTICK, 0)" as the first statement in the "FinishDownload" subroutine? The fix will not work unless it is in there. If you did that and still got the error then you may also need to disable and reenable the timer in other locations inside the callback. It is all a matter of timing...
WinBatch has a rather large regression test suite for WIL dialogs. The individual tests make extensive use of short timers to verify the predicted effects of various dialog function calls. It is standard practice to disable and reenable timers at the beginning and ending of callbacks case statements that take any time to process. The reason was all the false test failures caused by timers that changed depending on the version of WIL, the system CPU speed, and the version of Windows.
Again, the difference in versions has nothing to do with coding changes in the WIL dll. It does have to do with the vagaries of Windows timer messages.
case DIALOG_TIMERTICK
DialogProcOptions(DialogHandle_HttpDownload, DIALOG_TIMERTICK, 0)
x=x+1
if isdefined(doonce) then
hProgBar=udfProgressBarCreate(3,5,70,420,10,1,titlebar) ;1
percentdone=0
gosub StartDownload
drop(doonce)
endif
;StartTime=TimeYmdHms()
sofar=percentdone
;while TimeYmdHms()==StartTime
; Add this right before the problematic DllCall in the while loop
if openreqhandle == 0 then
DialogControlSet(DialogHandle_HttpDownload, 6, 3, "Invalid request handle")
break
endif
;if !breadbuf then return 1
r=dllcall(wininet,long:"InternetReadFile",long:openreqhandle,lpbinary:databuf,long:btoread,lpbinary:breadbuf)
bread=BinaryPeek4(breadbuf,0)
totalread=totalread+bread
DialogControlSet(DialogHandle_HttpDownload, 6, 3, StrCat(totalread," of ",size," bytes"))
dllcall(kernel32,long:"WriteFile",long:hfile,lpbinary:databuf,long:bread,lpbinary:bwrittenbuf,lpnull)
;if bread==0 then break
;endwhile
;pause(totalread,size)
if size <> "Unknown" then percentdone=int(%totalread%.00/size*100)
if percentdone>sofar
for x = (sofar+1) to percentdone
udfProgressBarTick(hProgBar)
next x
endif
if bread==0
gosub FinishDownload
return 1 ;success (file complete)
endif
DialogProcOptions(DialogHandle_HttpDownload, DIALOG_TIMERTICK,250)
break
Should eliminate most of the timer related issues.
One quick note: the reason the first suggestion worked was because I foolishly executed it inside the WBS debugger. The debugger reduces performance by about 50%, which is enough to make the timing work in the context of event-driven UDP callback reentry.
Thank you for your latest note about the WBS debugger's impact on performance and for the fix to resolve the 3023: Invalid Binary Data handle passed error in WinBatch 2025A. Initially, I tried your modified DIALOG_TIMERTICK case exactly as provided, but it didn't work because disabling the timer at the start and removing the while loop caused the download to stop after reading only one chunk of data. However, I integrated the line DialogProcOptions(DialogHandle_HttpDownload, DIALOG_TIMERTICK, 0) into my original script, and after further refinement, I placed it in the FinishDownload subroutine as you originally suggested:
:FinishDownload
if IsDefined(DialogHandle_HttpDownload) then DialogProcOptions(DialogHandle_HttpDownload, DIALOG_TIMERTICK, 0)
This resolved the issue in WinBatch 2025A—the 3023 error no longer occurs, and the download completes with the progress bar updating as expected. I also removed the second line (DialogProcOptions(DialogHandle_HttpDownload, DIALOG_TIMERTICK, 250)) as it seemed unnecessary after disabling the timer; please let me know if I misunderstood its purpose.
Your note about the WBS debugger reducing performance by 50% explains why the script worked in your initial test. It also confirms that WinBatch 2025A runs faster than 2024A in normal execution. Since my script worked in 2024A across multiple systems for a year without issues, I can conclude that 2024A's slower performance avoided the race condition, while 2025A's performance improvements (running faster) exposed the issue, leading to the 3023 error. While I understand there were no undocumented changes in terms of stricter handle validation, the performance difference between 2024A and 2025A is a significant runtime behavior change that impacted my script's compatibility. Documenting such performance improvements in the release notes could have helped narrow down the issues, but ultimately your help was the fastest and much appeciated.
Thank you for your assistance in resolving this issue. I'll continue using the fixed script in 2025A.
Full Subroutine (2025A):
#DefineSubroutine procHttpDownload(DialogHandle_HttpDownload, EventCode_HttpDownload, ControlNum_HttpDownload, Res4, Res5)
;---------------------------------------------------------------------------------------------
;This function is called from above - only the function above should be called directly.
; (Dialog callback routine)
DIALOG_INIT = 0
DIALOG_TIMERTICK = 1
DIALOG_PUSH = 2
switch(EventCode_HttpDownload)
case DIALOG_INIT
doonce=@TRUE
x=0
DialogProcOptions(DialogHandle_HttpDownload, DIALOG_TIMERTICK, 1)
DialogProcOptions(DialogHandle_HttpDownload, DIALOG_PUSH, 1)
break
case DIALOG_PUSH
if ControlNum_HttpDownload == 1 ;CANCEL
gosub FinishDownload
if FileExist(localfile) then FileDelete(localfile)
Exit
return 99
endif
break
case DIALOG_TIMERTICK
x=x+1
if isdefined(doonce) then
hProgBar=udfProgressBarCreate(3,5,70,420,10,1,titlebar) ;1
percentdone=0
gosub StartDownload
drop(doonce)
endif
StartTime=TimeYmdHms()
sofar=percentdone
while TimeYmdHms()==StartTime
if openreqhandle == 0 then
DialogControlSet(DialogHandle_HttpDownload, 6, 3, "Invalid request handle")
break
endif
r=dllcall(wininet,long:"InternetReadFile",long:openreqhandle,lpbinary:databuf,long:btoread,lpbinary:breadbuf)
bread=BinaryPeek4(breadbuf,0)
totalread=totalread+bread
DialogControlSet(DialogHandle_HttpDownload, 6, 3, StrCat(totalread," of ",size," bytes"))
dllcall(kernel32,long:"WriteFile",long:hfile,lpbinary:databuf,long:bread,lpbinary:bwrittenbuf,lpnull)
if bread==0 then break
endwhile
if size <> "Unknown" then percentdone=int(%totalread%.00/size*100)
if percentdone>sofar
for x = (sofar+1) to percentdone
udfProgressBarTick(hProgBar)
next x
endif
if bread==0
gosub FinishDownload
return 1 ;success (file complete)
endif
break
endswitch
return -2
:StartDownload
;dll handles
wininet=dllload(StrCat(DirWindows(1),"wininet.dll"))
kernel32=dllload(StrCat(DirWindows(1),"kernel32.dll"))
;init connection
tophandle=dllcall(wininet,long:"InternetOpenA",lpstr:"Microsoft Internet Explorer",long:1,lpnull,lpnull,long:0) ;INTERNET_OPEN_TYPE_DIRECT
connecthandle=dllcall(wininet,long:"InternetConnectA",long:tophandle,lpstr:host,long:80,lpstr:username,lpstr:password,long:3,long:0,long:0) ;INTERNET_DEFAULT_HTTP_PORT INTERNET_SERVICE_HTTP
openreqhandle=dllcall(wininet,long:"HttpOpenRequestA",long:connecthandle,lpstr:"GET",lpstr:object,lpnull,lpstr:referer,lpnull,long:67108864,long:0) ;INTERNET_FLAG_NO_CACHE_WRITE
; Check if openreqhandle is valid
if openreqhandle == 0 then
DialogControlSet(DialogHandle_HttpDownload, 6, 3, "Failed to open HTTP request")
DllCall(wininet, long:"InternetCloseHandle", long:tophandle)
DllFree(wininet)
DllFree(kernel32)
return 0
endif
;set recieve timeout
toutbuf=binaryalloc(4)
binarypoke4(toutbuf,0,timeout*1000)
dllcall(wininet,long:"InternetSetOptionA",long:openreqhandle,long:6,lpbinary:toutbuf,long:4) ;INTERNET_OPTION_RECEIVE_TIMEOUT
binaryfree(toutbuf)
sendreq=dllcall(wininet,long:"HttpSendRequestA",long:openreqhandle,lpstr:"",long:0,lpstr:"",long:0)
if sendreq == 0
DialogControlSet(DialogHandle_HttpDownload, 6, 3, "HttpSendRequestA failed")
DllCall(wininet, long:"InternetCloseHandle", long:tophandle)
DllFree(wininet)
DllFree(kernel32)
return 0
endif
;query status code
indexbuf=binaryalloc(4)
infobuf=binaryalloc(4)
infobufsize=binaryalloc(4)
binarypoke4(infobufsize,0,4)
dllcall(wininet,long:"HttpQueryInfoA",long:openreqhandle,long:19|536870912,lpbinary:infobuf,lpbinary:infobufsize,lpbinary:indexbuf) ;HTTP_QUERY_STATUS_CODE|HTTP_QUERY_FLAG_NUMBER
stcode=binarypeek4(infobuf,0)
;query size
binarypoke4(indexbuf,0,0)
binarypoke4(infobuf,0,0)
dllcall(wininet,long:"HttpQueryInfoA",long:openreqhandle,long:5|536870912,lpbinary:infobuf,lpbinary:infobufsize,lpbinary:indexbuf) ;HTTP_QUERY_STATUS_CODE|HTTP_QUERY_FLAG_NUMBER
size=binarypeek4(infobuf,0)
If "%size%"=="" || size==0
size="Unknown"
hfile=-1
bread=0
dllcall(wininet,long:"InternetCloseHandle",long:tophandle)
dllfree(wininet)
dllfree(kernel32)
Display(1,stcode,localfile)
wq=AskYesNo("Stcode:%stcode%", "Error connecting to URL, Continue?")
if wq==@no then exit
return 0 ;stcode ;failure (no download attempt <>200)
goto daEnd_Sub
Endif
binaryfree(infobuf)
binaryfree(indexbuf)
binaryfree(infobufsize)
if stcode==200 ;OK
;create localfile
hfile=dllcall(kernel32,long:"CreateFileA",lpstr:localfile,long:1073741824,long:0,lpnull,long:2,long:128,lpnull) ;GENERIC_WRITE CREATE_ALWAYS FILE_ATTRIBUTE_NORMAL
if hfile==-1
dllcall(wininet,long:"InternetCloseHandle",long:tophandle)
dllfree(wininet)
dllfree(kernel32)
return 0 ;hfile
endif
;download
totalread=0
bread=""
btoread=204800
databuf=binaryalloc(btoread)
if databuf == 0 then
DialogControlSet(DialogHandle_HttpDownload, 6, 3, "Memory allocation error for databuf")
gosub FinishDownload
return 0
endif
BinaryEodSet(databuf, 0)
breadbuf=binaryalloc(4)
if breadbuf == 0 then
DialogControlSet(DialogHandle_HttpDownload, 6, 3, "Memory allocation error for breadbuf")
binaryfree(databuf)
gosub FinishDownload
return 0
endif
BinaryEodSet(breadbuf, 0)
BinaryPoke4(breadbuf, 0, 0)
bwrittenbuf=binaryalloc(4)
if bwrittenbuf == 0 then
DialogControlSet(DialogHandle_HttpDownload, 6, 3, "Memory allocation error for bwrittenbuf")
binaryfree(databuf)
binaryfree(breadbuf)
gosub FinishDownload
return 0
endif
BinaryEodSet(bwrittenbuf, 0)
BinaryPoke4(bwrittenbuf, 0, 0)
else
dllcall(wininet,long:"InternetCloseHandle",long:tophandle)
dllfree(wininet)
dllfree(kernel32)
return 0 ;stcode ;failure (no download attempt <>200)
endif
return
:FinishDownload
; Disable the dialog timer to prevent further ticks
if IsDefined(DialogHandle_HttpDownload) then DialogProcOptions(DialogHandle_HttpDownload, DIALOG_TIMERTICK, 0)
; Close file
dllcall(kernel32,long:"_lclose",long:hfile)
; Free mem
binaryfree(databuf)
binaryfree(breadbuf)
binaryfree(bwrittenbuf)
; Close ihandles
dllcall(wininet,long:"InternetCloseHandle",long:tophandle)
; Free dlls
dllfree(wininet)
dllfree(kernel32)
if r==0 then return 0 ;-2 ;timeout error
return
:daEnd_Sub
:cancel
#EndSubroutine
Quote from: td on April 07, 2025, 02:05:16 PMDid you add the line "DialogProcOptions(DialogHandle_HttpDownload, DIALOG_TIMERTICK, 0)" as the first statement in the "FinishDownload" subroutine? The fix will not work unless it is in there.
Tony, yes I did. I think the issue about timing was important to resolve. I did think the script(s) were a lot of work just to download a file, unless Dropbox requires special attention. To that point, I had tested a dropbox sample download about 5 years ago using the CLR. Was frustrated back then until you helped me out with the TLS 2 protocol. I placed the code below and it should work for anyone downloading the .exe in versions of WB > 2013. I tried it with the OP's url but got an error that the file had been deleted or couldn't be found....
;Dropbox File Download Test using CLR
;Stan Littlefield, 11/11/2020
;====================================================================
url = "https://www.dropbox.com/s/example/fsg_rsupport_install_v4.0.exe"
dest = "C:\temp\fsg_rsupport_install_v4.0.exe"
if fileexist(dest) Then filedelete(dest)
ObjectClrOption("useany", "System")
oWeb = ObjectClrNew('System.Net.WebClient')
;TLS1.2 needed since 1st April 2020
objUri = ObjectClrNew('System.Uri', url)
objSvcManager = ObjectClrNew('System.Net.ServicePointManager')
protocols = ObjectClrType("System.Net.SecurityProtocolType",3072|768|192|48|0)
objSvcManager.SecurityProtocol = protocols
oWeb.DownloadFile(url,dest)
oWEb = 0
if fileexist(dest) Then display(3,"download successful",dest)
Exit
Quote from: usheretov on April 08, 2025, 02:12:30 AMIt also confirms that WinBatch 2025A runs faster than 2024A in normal execution. Since my script worked in 2024A across multiple systems for a year without issues, I can conclude that 2024A's slower performance avoided the race condition, while 2025A's performance improvements (running faster) exposed the issue, leading to the 3023 error. While I understand there were no undocumented changes in terms of stricter handle validation, the performance difference between 2024A and 2025A is a significant runtime behavior change that impacted my script's compatibility. Documenting such performance improvements in the release notes could have helped narrow down the issues, but ultimately your help was the fastest and much appeciated.
It is simply not the case that 2025a performs better than 2024b. We have benchmark tests that verify this. The changes between the two simple did not modify 2025A's overall performance. If 2025a had any measurable performance advantage, I can assure you that it would be bragged about.
As I mentioned earlier, timer messages are variable in frequency on either side of about 20 milliseconds. When you are firing one every 1 millisecond, you are vulnerable to the vagaries of the OS. In your case, there are many explanations for why the flaws in the script did not show up until 2025a, but performance or anything else under ILC LLC's control is not one of them.
I this point, I should go into a long explanation of how the OS works under the hood as relates to this subject, but it's probably better to move on.
A code modification in the next release will hopefully alleviate most timer problems, such as the one reported by the OP of this topic.