SDIO_x64_R817.exe A...
 
Notifications
Clear all

We had a major storm through here recently and we suffered damage to the house roof and ceilings. I just received the quote to repair. I’m hoping that a small fraction of the 80,000 odd people that download SDIO and/or Desktop Info every month won’t mind chipping in a few dollars to help out. Click on the big blue button at the bottom of the page to help us keep a roof over our heads, literally!

Guests have read-only access to our forums. If you wish to participate you will need to register. Be sure to activate your account from the email sent to you when you register.

SDIO_x64_R817.exe AV (0xC0000005) in script/automated mode — manual GUI install OK

8 Posts
2 Users
0 Reactions
967 Views
(@nistee)
Active Member Registered
Joined: 4 months ago
Posts: 4
Topic starter  
Hello,

I observed an access violation when running SDIO_x64_R817.exe in scripted/automated mode. Manual GUI-based download+install does NOT reproduce the problem.

Steps I took:
1. Generated an automatic script (attached as topgrade_sdio_script.txt) and ran SDIO with:
C:\Windows\System32\sudo.exe 'C:\Users\<user>\SDIO_x64_R817.exe' -script '...\\topgrade_sdio_script.txt'
(Topgrade invoked SDIO under the sudo wrapper; used_sudo = true.)
2. Result: process crashed with EXCEPTION_ACCESS_VIOLATION (0xC0000005). Topgrade captured .dmp files via procdump.
3. I also tried:
- invoking the same sudo wrapper directly (it returned RPC error 0x800706BE),
- running the EXE elevated directly (Start-Process -Verb runAs) — interactive manual GUI install does not reproduce the crash.
4. Artifacts attached: topgrade_sdio_artifacts.zip — contains the generated script, sdio_stdout/stderr, sd io_run_summary.json, the .dmp files in sdio_dumps, and analyzer logs.

Observations:
- Crash only seen when run via script/automation or via the wrapper; interactive GUI install succeeds on the same machine.
- The attached run summary shows exit_code = -1073741819 (0xC0000005) and used_sudo = true.

Requests:
- Can you confirm whether r817 contains a regression for scripted installations?
- Any immediate mitigation suggestions (e.g., avoid a specific script command such as `restorepoint`, or a recommended wrapper)?

Thank you — I can re-run with further instrumentation if needed.

This topic was modified 4 months ago 2 times by nistee

   
Quote
Glenn
(@glenn)
Member Admin
Joined: 7 years ago
Posts: 1811
 

I can't account for "sudo.exe" but I'd be interested in looking at the script and log files.


   
ReplyQuote
(@nistee)
Active Member Registered
Joined: 4 months ago
Posts: 4
Topic starter  

@glenn gist on github  /niStee/a7900a329a3d3b78e2e21442b0ab2119

Unfortunately, I can't add the script as codeblock or link it to the Gist here.

This post was modified 4 months ago by nistee

   
ReplyQuote
Glenn
(@glenn)
Member Admin
Joined: 7 years ago
Posts: 1811
 

@nistee try to upload a zip file to mega:

https://mega.nz/filerequest/431V5kZaGhc


   
ReplyQuote
(@nistee)
Active Member Registered
Joined: 4 months ago
Posts: 4
Topic starter  

 gist.github. com /niStee/a7900a329a3d3b78e2e21442b0ab2119


   
ReplyQuote
Glenn
(@glenn)
Member Admin
Joined: 7 years ago
Posts: 1811
 

@nistee There's no regression issues. I'll test your script.


   
ReplyQuote
Glenn
(@glenn)
Member Admin
Joined: 7 years ago
Posts: 1811
 

@nistee You need to move the call to "init" up the script, right after "logdir" say.

Edit: I've added checks to make sure the script engine is initialised.


   
ReplyQuote
(@nistee)
Active Member Registered
Joined: 4 months ago
Posts: 4
Topic starter  

Thanks


   
ReplyQuote
Glenn's Page