Page 2 of 2

Re: Bug in latest stable version (x64 8.1.0.16)

PostPosted: Fri Jun 16, 2017 7:57 pm
by Iggiz
VistaFirewallControl wrote:What is the software created the ramdisk? The ramdisk software was updated recently?
What is the OS version?


SoftPerfect RAM Disk 3.4.8 64bit - I did not update it recently, having it installed for 6 months

Windows 10 pro x64 German, version 1607


VistaFirewallControl wrote:W10FC v8.1 64 bit Free/German Edition. Correct?


yes


VistaFirewallControl wrote:Actually there were no any changes in the programs detection since v6....
We have just tried to reproduce the problem on the "normal" temp folder. Everything worked correctly.
We would like to reproduce with the ramdisk though.
The temp folder was reassigned by TEMP variable of the environment? Or anyhow else?



Yes, both temp environment vars were changed and point to R:\Temp

Re: Bug in latest stable version (x64 8.1.0.16)

PostPosted: Sat Jun 17, 2017 9:59 am
by VistaFirewallControl
Please stay tuned, we are reproducing.
We will be back on the results.

Re: Bug in latest stable version (x64 8.1.0.16)

PostPosted: Sun Jun 18, 2017 5:16 pm
by VistaFirewallControl
Well what we did
-Checked the firewall 7.5 vs 8.1 sources that were strictly equal for removable drives interpretation.
-Installed fresh Win10/1607 64/En (on a VM) + SoftPerfect RAM Disk 3.4.8 64bit + W10FC 8.1
-Created R: and set TEMP\TMP=R:
(R:, not R:\Temp however, as appeared for successful %TEMP%=R:\Temp settings the Temp folder on R: has to be precreated, the system was not able to create the subfolder itself. Have we missed something? How did you create the Temp subfolder on R:? Just out of curiosity)
-Installed ProcExp.exe in C:\ProgramFiles\ProcessExplorer)
- Launched Procexp.exe and it created R:\procexp64.exe
- Forced ProcExp to Check VirusTotal, it was detected (so blocked once) by the firewall, set with EnableAll and then VT checking worked fine
- Performed reboot
- Launched Procexp.exe and it created R:\procexp64.exe again
- Forced ProcExp to Check VirusTotal and it was not blocked. Moreover (under Allowed events enabled) it showed
2017:06:18|09:18:02|Allowed|1|IPv4 TCP http://www.virustotal.com/74.125.34.46:443(49790)|Sysinternals Process Explorer|EnableAll/EnableAll Outgoing|R:\procexp64.exe
as expected.

So no problems were revealed.

Might we ask you to try the following.
- Set in the Ram disk R: "mount as removable". Helped?
- check the ProcessExplorer icon in the firewall list before\after the ProcessExplorer connection fails. Is it "red cross" or the normal application icon?
(The normal icon is a sign of the procexp permissions were reapplied after the RamDrive is recreated)
If it's possible the firewall should show in the balloon, something like "Process Explorer .... reapplied", you can see the message while unmounting/ mounting R: back in runtime (without reboot).

For instance when ProcExp access is successful (after detection and applying EnableAll, stop ProcExp and unmount R
The firewall should change ProcExp icon to the red cross.
Then please mount R: back
The firewall should show "ProcessExplorer ... reapplied" in the balloon.
If R:\procexp64 _already_ exists the icon will be changed back accordingly.
Do you see "reapplied" while doing that?
That may be critical. The explanation is below.

For applications located on removable drives, the firewall has to reapply permissions for such apps when removable media is mounted (back or initially). Skipping the details of the reapplying need for the simplicity, have to say that's just important. Otherwise you will have Detection (and consequent blocking) for already listed apps on all removable drivers.
How it works. A mounting application (RAM disk) sends message (WM_DEVICE_CHANGE) on its own to all the other applications including the firewall. The firewall picks up the message and reapplies required permissions. If the message does not reach the firewall for a reason, the permissions are not reapplied and the problem arises.
Typically a regular application can't send messages to UAC-ed/elevated applications (for native Windows security reason)
So if the firewall panel is launched as Admin, such problem may happen.
An application may skip sending such messages for internal applications reasons as well.
That's why "R - mount as removable" may be helpful.


Looking forward to hear from you.

Re: Bug in latest stable version (x64 8.1.0.16)

PostPosted: Mon Jun 19, 2017 4:17 am
by Iggiz
I tested it on a virtual machine today and I have the same problem there too!

Windows 10 x64 enterprise 1607


I tried to remove the ramdisk when it failed to connect and added it back, then it worked. That's not really a good solution though lol


here is a video:
https://drive.google.com/open?id=0B5by5 ... W0zMVBqUkE



Edit:
mount as removable doesn't work, same problem.

Re: Bug in latest stable version (x64 8.1.0.16)

PostPosted: Mon Jun 19, 2017 10:50 am
by PietO
just for info: i'm running win7-64 bit with a RAM-disk where %temp% and %tmp% are located in a subdirectory of the ramdisk (in my case X:\<user>\temp). The implementation of the RAM-disk structure is using Superspeed LLC V6 (64 bit version) where the folder-structure is first manually made and saved as "image" which is preloaded at startup of the PC (option of Superspeed LLC).

Process-explorer X64 runs thus from Ramdisk X:\users\pieto\procexp64.exe wich is in Programlist on WxFC without problems.

Regards.

Re: Bug in latest stable version (x64 8.1.0.16)

PostPosted: Mon Jun 19, 2017 10:52 am
by VistaFirewallControl
>I tested it on a virtual machine today and I have the same problem there too!

Thank you for the details and the video.
Actually some our installation parameters were a bit different, VMWare instead of Virtual Box was used as well. May be it's the key.
We will try to make another experiment with exactly the same settings.

For now we understand the problem as a time race.
If RamDisk and the firewall service starts " unsuccessfully" at the same time, the device change message can be lost and the required permissions could be not reapplied accordingly.
Otherwise the permissions reapplying would be successful.
We need to verify the hypothesis.
If you could send us the entire VirtualBox it could speed up the process.

Re: Bug in latest stable version (x64 8.1.0.16)

PostPosted: Tue Jun 20, 2017 12:22 pm
by VistaFirewallControl
Following the video we executed the same steps precisely (on different Win10 edition/VM though).
The problem was reproduced twice during 15 reboots only. So very unstable.
After started playing with RamDisk options, i.e. HardDiskEmulation checked/remounted/unchecked/remounted (*), the next 15 reboots did not show any problem.
ProcExp access was successful after reboot.

The only recommendations left are
- do not start ProcExp immediately after reboot, let the firewall load itself in full, let the firewall show the tray icon for instance.
- put procexp to non-volatile writable folder. This prevents from creating temporary files principally.
- update RamDisk. v 3.8 is discontinued. Honestly it was even hard to find the exact version.

The issue is actually very specific and compatibility related.
If you would like us to continue the investigations we would need more details for the reproduction
- do you have other portable (non system) drives connected/mounted to the system?
Maybe it's a detail preventing from the reproduction
- The entire your VM sent to us (if it's possible)

Please realize we do not decline the problem exist.
But in order to be helpful we need to see the problem not on a video only.


(*)We have no idea whether it could affect the problem, "After" does not mean "due to" obviously.

Re: Bug in latest stable version (x64 8.1.0.16)

PostPosted: Tue Jun 20, 2017 3:51 pm
by Iggiz
VistaFirewallControl wrote:Following the video we executed the same steps precisely (on different Win10 edition/VM though).
The problem was reproduced twice during 15 reboots only. So very unstable.
After started playing with RamDisk options, i.e. HardDiskEmulation checked/remounted/unchecked/remounted (*), the next 15 reboots did not show any problem.
ProcExp access was successful after reboot.

The only recommendations left are
- do not start ProcExp immediately after reboot, let the firewall load itself in full, let the firewall show the tray icon for instance.
- put procexp to non-volatile writable folder. This prevents from creating temporary files principally.
- update RamDisk. v 3.8 is discontinued. Honestly it was even hard to find the exact version.


It's ok, I know how to workaround it so it's not a big problem for me. Just wanted to report the issue to you guys so you can fix it if you want, other users might get the same problem too. I can also use procexp64.exe directly and have no problems.



VistaFirewallControl wrote:The issue is actually very specific and compatibility related.
If you would like us to continue the investigations we would need more details for the reproduction
- do you have other portable (non system) drives connected/mounted to the system?
Maybe it's a detail preventing from the reproduction
- The entire your VM sent to us (if it's possible)

Please realize we do not decline the problem exist.
But in order to be helpful we need to see the problem not on a video only.


(*)We have no idea whether it could affect the problem, "After" does not mean "due to" obviously.



I got the VM from microsoft, I only installed 7zip into it. Rest is original.

Get it here for free: https://developer.microsoft.com/en-us/m ... tools/vms/

Re: Bug in latest stable version (x64 8.1.0.16)

PostPosted: Tue Jun 20, 2017 4:12 pm
by VistaFirewallControl
>It's ok, I know how to workaround it so it's not a big problem for me.

Is it HardDiskEmulation rechecking? Making ProcExp to work without a mountable temp involved? or something else we are not aware of?

>Just wanted to report the issue to you guys so you can fix it if you want, other users might get the same problem too.

Thank you very much. We are keen to fix, just need something to catch at beyond the obviously convincing video

>I got the VM from microsoft, I only installed 7zip into it. Rest is original.

Thank you, hopefully tomorrow we will be back with a result

Re: Bug in latest stable version (x64 8.1.0.16)

PostPosted: Tue Jun 20, 2017 5:29 pm
by VistaFirewallControl
Hmm...
Got the VM (the latest, appeared newer than on your video, VMWare though) from the link, installed the required components, configured them and..... nothing is wrong. 10 reboots made one by one.
Should we try VBOX image as well?
Lost in conjectures.
BTW ProcExp refreshes the VT results on its own after the start, no right clicking is required, RightClicking the VT is successful as well.
Do you have a hypothesis?