James Russell

No no, thank you! You identified the problem and corrected it in no time at all!

AIMtk installed cleanly as far as I could see, with all components selected and RAM disks work as expected, I have one running, but I am unable to mount a VMDK image using MountImg. From what I could see, because it spawns quickly, MountImg calls aim_cli and aim_ll with command lines similar to these: "C:\Program Files\AIM Toolkit\aim_cli.exe" --name=AIM99c4766dcc7 --filename="C:\Virtual Machines\Storage\Shared.vmdk" "C:\Program Files\AIM Toolkit\aim_ll.exe" -a -t proxy -o shm,hd,rw,fix -f AIM99c4766dcc7...

Hi! Thank you for all of the test builds, I checked a couple of minutes ago, but I'm afraid I am still seeing the same behavior. I looked into it a bit more, all 3 domains are accessible from my network, nslookup reports the correct IPs and I can get to them through a web browser, for example. Just in case, I checked from networks of 3 other ISPs (Orange, Vodafone and Digi, none block access), their default resolvers also point to the correct addresses. The only thing I can think of as to why it...

Sorry for the delay! I just saw both yours and Sam's messages. I don't think that code is up to date, the last entry in the log is from 2017... My workaround is to disable IPv6, if I only have an IPv4 link it works as expected. Run "ncpa.cpl" or go to the Network Connections part of the Control Panel, right click your adapter and choose Properties, lastly untick "Internet Protocol Version 6 (TCP/IPv6)". Disconnect and connect to the network again, just so the OS knows to use IPv4 only and try ag...

I just checked but behaves the same: if I have IPv6 enabled for the network adapter I get the bad cast exception. Disabling IPv6 and having only IPv4 makes it work. I don't think the logs are much to go by, but I have attached them to this message, first 2 were when IPv6 was enabled, the last one when I was only using IPv4.

Oh! Thank you, it's appreciated! I had attached the part of the log where that exception happened in a comment because I had forgotten to in the bug report, but it seems the comment didn't go through. I wonder if it has to ISPs or there is a problem in the code that handles the connection when IPv6 is present (does Windows default to if both v4 and v6 have valid links?). I noticed yesterday that disabling IPv6 support in the adapter properties made it work, re-enabling it triggered the exception...

Exception when trying to update indexes: std::bad_cast

I was about to open a ticket for this, or contact @marha, but I don't know whether that would be useful or not. In my case, I was connecting to machines using various versions of OpenSSH servers, from what is on Debian Buster to that of Arch and Plink outputs the same. Because the previous build seems to work as expected, I can only suppose that something is amiss, maybe the shipping build of Plink has a bug? In any case, replacing the Plink exe for that of the current PuTTY makes things work in...