cpvnm v1.2(7) in Win VM crashing

[TabSel]

The VM ethernet HAS a dedicated MAC that differs from the Host...

[TabSel]

In the win 8.1 Parallels VM:

Choosing "- none -" eth interface, the cpvnm service is idle and does not crash.
Choosing the emulated intel pro eth interface, the cpvnm service consumes a lot of cpu cycles until it crashes.

[TabSel]

any idea what I can do in addition to help you track this down?

[CopperPhil]

Not really...

Do you have also CopperLan installed on the MacOSX hosting the VM? If so, does it change something in the VM if you select no Ethernet interface on the MacOSX?

When the CPVNM is running high CPU on the VM, can you check if the used memory by this process is growing indefinitely until the crash?

[TabSel]

yes, Copperlan is installed on the VM host (Mac OS X) and the VM Client (Win8.1x64).

Memory usage is growing up to about 10MB until it crashes, yes.

[CopperPhil]

And... does it change something in the VM if you select no Ethernet interface on the MacOSX CopperLan settings?

[TabSel]

yes: chosing " - None - " eth Interface on the VM host CP results in the Win VM CPVNM running stable!

the Win VM CPVNM crashes only when both machines use a eth Interface.

The VM uses a bridged Network with a dedicated MAC. I have no issues with for example rtpMIDI. Both the Host and the VM are seen as "independant machines" across the Network, everything works as expected, despite CPVNM.

[CopperPhil]

Rtp and other protocols are working fine because they are based on IP... CopperLan is not IP based and is running its own protocol on top of layer 2.

There is probably a weird issue in the host<->VM network bridge causing malfunction in the Windows network stack... probably around the packet routing for protocol that are not IP based.

I'm afraid this is a Parallels issue, not CopperLan...

[TabSel]

but it worked with v1.3(1)

it did not work with v1.2(7), and now it does not work with v1.3.(2) again...

[CopperPhil]

There was absolutely no change in the CopperLan network stack between these versions. The changes are located in the top level APIs and in the CopperLan Manager application, nothing related to the physical network transport or the CopperLan core engine.

Sincerely if the problem back and forth between CopperLan installation, it's certainly a side effect due to something external to CopperLan.

In order to investigate further we should install here a similar configuration with Parallels and Win8.1, hoping to see the same problem. I'm very sorry, we keep this problem in mind but we have no time for it right now.