No scan results for IP range 192.168.1.1 - 255 in the new version

wondering about new unwanted DHCP Servers 192.168.1.1 and 192.168.178.1 found in our LAN by the DHCP Server Discovery but no scan results at all were shown by a scan of theese ranges, I did a scan with an older 32-bit version.

Yes, scan settings are absolutely identical in ALL tabs - (except "timeout, ms" in Browsing tab doesn't exist any more) -
and
No, it is not a firewall problem.
and
Yes, it's the same from a different 64-bit computer.
and
Yes, it's the same for the 32-bit version of 6.0.6.

Any ideas?
I think it's supposed to be a bug in 6.0.6.

Unfortunately I don't have any other older versions any more to check which version started showing this behaviour.

I am afraid I am out of ideas in this case. It's by no means a widespread issue as thousands of users have updated to the latest version and no one has reported an issue like this.

I suggest to try sniffing ICMP traffic in and out of the computer using Wireshark to see whether it actually sends echo requests and receives any response. We can also do a teamviewer session where I could have a look at what's happening.

I have found that depending on the anti-virus software used on the client you are trying to scan/ping it can block ping for a while or all traffic from your IP address. If you try to scan the same subnet too quickly the AV software may block the scan as a threat. Plus the more you are scanning a device the more AV software can think it is a threat I have this happen all the time. I need the client information but I want my AV software to protect the computer so there is a hard balance between the two. I hope that helps -WS

Basically what happens is this:
Network Scanner discovers devices by sending an ICMP request aka ping and an ARP request. As some devices don't respond to ICMP requests, sending an ARP request is the only way to detect them.

The router silently drops the request as non-routable. In this case no device is detected as there is no response.

The router responds to the request with its own MAC address. In this case all IP addresses are incorrectly detected as devices.

The router runs a proxy ARP service and correctly forwards ARP back and forth. In this case the devices are detected normally.

Your network seems to be configured as in scenario 3, though scenarios 1 and 2 are more common. As of version 6.0.4 Network Scanner no longer sends ARP requests when scanning a different subnet, because in scenario 2 it detects devices that are not there on every IP address. We did this due to receiving a lot of messages from users claiming Network Scanner was detecting non-existent devices.

So the latest build simply has an option that allows ARP requests to be sent to a different subnet, which works for scenario 3, but for scenario 2 it would produce false positives and should be disabled.

I'm having the exact same problem, I've been using this prog for many years and the latter versions are giving me this problem (no results), FYI, I'm running version 6.0.9 x64 on a Win10 machine. I had a very old version nearby (version 3.5 ) and ran it successfully, I can see the results and no problems at all. From what I read above, it looks like version 6.0.3 was still working, would it be possible to let us download this file again ?
Thank you.

With or without the Allow ARP outside current subnet option on, it doesn't change anything, that's the first thing I tried since you have recommended it to others previously.

I have no recent version working, I have only a very old one the 3.5 that does work perfectly, that's why I asked if I could download the version 6.0.3, is it possible to make it available again so I can test with it ?

In fact it's almost fixed... I can see the results now but the MAC address column is still empty !! I can see the IP address, the host names and the response time, but nothing shows up in the MAC address column (expect the column name itself). Should I tick some other option somewhere ?

Ok, I can see the MAC addresses now, in fact I had to check the "Resolve MAC addresses" option in the "Additional" tab, I thought this option was used to resolve MAC addresses to NIC vendors, wrong interpretation I guess