on windows

Hi there,

When I run a process twice in windows, crystal seems to hang.
I was wondering if this is a known issue for the windows version of crystal? (I know windows support is in development). I’m using crystal-nightly via scoop.

Here’s a reproduction:

#>crystal -v
#Crystal 1.7.0-dev [1c33a0b] (2022-10-29)

#LLVM: 13.0.0
#Default target: x86_64-pc-windows-msvc

def run_proc(command, a)
  stdout =
  stderr =
    mini_proc =, args: a, output: stdout, error: stderr)
    if mini_proc.success?
      return stdout.to_s
      return "error" #stderr.to_s
  rescue ex
    return "error"

# This part works fine on windows
puts "windows version"
puts run_proc("wmic", ["os", "get", "Caption", "/value"]).strip

# This part stalls after 'try wmic' and never prints the 'acting on ... ' messages
os_info = ""
puts "try uname"
if run_proc("uname", ["-a"]) == "error" # linux/mac/bsd fail
    puts "try wmic"
    if run_proc("wmic", ["os", "get", "Caption", "/value"]) == "error" # windows fail
        puts "acting on wmic fail"
        os_info = "Unknown"
    else # windows success
        puts "acting on wmic success"
        os_info = run_proc("wmic", ["os", "get", "Caption", "/value"]).strip
else # linux/mac/bsd success
    os_info = run_proc("uname", ["-a"])

puts os_info

It works for me:

$ crystal.exe run .test/
windows version
Caption=Microsoft Windows 11 Home

Fair enough, I was building it - I should have tested running it, but what about the second part?
The ‘acting on wmic fail/success’ ?
I hope that reproduces the issue for you.

My overall goal here is to write a function to tell me what OS the executable is running on. I’m able to get around this by running the commands once, storing the results, and then comparing them.

Thank you!

Oh, totally missed that. It’s hidden on the view pane and there’s no indication of scrollable overflow content.
Trying the entire program, it hangs after try wmic for me.

1 Like

It makes no difference whether you run directly or build and run the executable.

1 Like

I see this issue exists: Interpreter: Process#run broken with defunct child process
I see that 12241 is talking about child processes, but I wonder if this duplicate process calls is a related issue? Should I open a separate issue?
Thanks, Dustin

#12241 is specifically about the interpreter, this is outside the interpreter, so a different issue.