Welcome
Welcome to vistafirewallcontrol

You are currently viewing our boards as a guest, which gives you limited access to view most discussions and access our other features. By joining our free community, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content, and access many other special features. In addition, registered members also see less advertisements. Registration is fast, simple, and absolutely free, so please, join our community today!

Bug in latest stable version (x64 8.1.0.16)

Re: Bug in latest stable version (x64 8.1.0.16)

Postby Iggiz » Fri Jun 16, 2017 7:57 pm

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
Iggiz
 
Posts: 7
Joined: Thu Jun 15, 2017 10:42 pm

Re: Bug in latest stable version (x64 8.1.0.16)

Postby VistaFirewallControl » Sat Jun 17, 2017 9:59 am

Please stay tuned, we are reproducing.
We will be back on the results.
VistaFirewallControl
Site Admin
 
Posts: 1479
Joined: Fri Mar 27, 2009 11:25 am

Re: Bug in latest stable version (x64 8.1.0.16)

Postby VistaFirewallControl » Sun Jun 18, 2017 5:16 pm

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.
VistaFirewallControl
Site Admin
 
Posts: 1479
Joined: Fri Mar 27, 2009 11:25 am

Re: Bug in latest stable version (x64 8.1.0.16)

Postby Iggiz » Mon Jun 19, 2017 4:17 am

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.
Iggiz
 
Posts: 7
Joined: Thu Jun 15, 2017 10:42 pm

Re: Bug in latest stable version (x64 8.1.0.16)

Postby PietO » Mon Jun 19, 2017 10:50 am

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.
PietO
 
Posts: 192
Joined: Wed Mar 02, 2011 12:09 pm

Re: Bug in latest stable version (x64 8.1.0.16)

Postby VistaFirewallControl » Mon Jun 19, 2017 10:52 am

>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.
VistaFirewallControl
Site Admin
 
Posts: 1479
Joined: Fri Mar 27, 2009 11:25 am

Re: Bug in latest stable version (x64 8.1.0.16)

Postby VistaFirewallControl » Tue Jun 20, 2017 12:22 pm

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.
VistaFirewallControl
Site Admin
 
Posts: 1479
Joined: Fri Mar 27, 2009 11:25 am

Re: Bug in latest stable version (x64 8.1.0.16)

Postby Iggiz » Tue Jun 20, 2017 3:51 pm

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/
Iggiz
 
Posts: 7
Joined: Thu Jun 15, 2017 10:42 pm

Re: Bug in latest stable version (x64 8.1.0.16)

Postby VistaFirewallControl » Tue Jun 20, 2017 4:12 pm

>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
VistaFirewallControl
Site Admin
 
Posts: 1479
Joined: Fri Mar 27, 2009 11:25 am

Re: Bug in latest stable version (x64 8.1.0.16)

Postby VistaFirewallControl » Tue Jun 20, 2017 5:29 pm

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?
VistaFirewallControl
Site Admin
 
Posts: 1479
Joined: Fri Mar 27, 2009 11:25 am

Previous

Return to Specific behavior

Who is online

Users browsing this forum: No registered users and 0 guests

cron
suspicion-preferred