De-installing before upgrading?

[arakula]

On my XP guest, CopperLan runs, but it's attached to the "host only" network. I can see periodic activity on the network adapter, so it looks like it's running.

Setup VirtualBox Host-Only Ethernet Adapter (done via File / Global Settings / Network):
Adapter:
IPv4 address: 192.168.56.1
Mask: 255.255.255.0
DHCP Server:
Server Address: 192.168.56.100
Mask: 255.255.255.0
Lowest Address: 192.168.56.101
Highest Address: 192.168.56.254
This allows the guest to use DHCP on the network adapter attached to the host-only network.

I've experimented a little bit... running it as cpvnm -console, CPVNM shows a list of available commands, and then dies. Attaching a debugger to the dead process shows that it obviously died at the same offset; here's the disassembly for the function it dies in:

Code: Select all

000000014004E840 40 53            push        rbx 
000000014004E842 48 83 EC 20      sub         rsp,20h
000000014004E846 48 8B 51 20      mov         rdx,qword ptr [rcx+20h]
000000014004E84A 48 8B D9         mov         rbx,rcx
000000014004E84D 83 C9 FF         or          ecx,0FFFFFFFFh
000000014004E850 E8 8B FF FF FF   call        000000014004E7E0
000000014004E855 48 8B 03         mov         rax,qword ptr [rbx]
000000014004E858 C6 43 0D 01      mov         byte ptr [rbx+0Dh],1
000000014004E85C C6 43 0C 00      mov         byte ptr [rbx+0Ch],0
000000014004E860 48 8B CB         mov         rcx,rbx
000000014004E863 FF 50 38         call        qword ptr [rax+38h]
000000014004E866 44 0F B6 5B 0C   movzx       r11d,byte ptr [rbx+0Ch]
000000014004E86B 45 84 DB         test        r11b,r11b
000000014004E86E 75 51            jne         000000014004E8C1
000000014004E870 48 83 7B 18 00   cmp         qword ptr [rbx+18h],0
000000014004E875 74 1D            je          000000014004E894
000000014004E877 8B 53 30         mov         edx,dword ptr [rbx+30h]
000000014004E87A 48 8B 4B 18      mov         rcx,qword ptr [rbx+18h]
000000014004E87E 41 B8 01 00 00 00 mov         r8d,1
000000014004E884 48 8B 09         mov         rcx,qword ptr [rcx]
000000014004E887 FF 15 3B 6B 08 00 call        qword ptr [1400D53C8h]
000000014004E88D 85 C0            test        eax,eax
000000014004E88F 0F 94 C1         sete        cl   
000000014004E892 EB 0B            jmp         000000014004E89F
000000014004E894 8B 4B 30         mov         ecx,dword ptr [rbx+30h]
000000014004E897 FF 15 9B 6B 08 00 call        qword ptr [1400D5438h]
000000014004E89D 32 C9            xor         cl,cl
000000014004E89F 0F B6 43 0C      movzx       eax,byte ptr [rbx+0Ch]
000000014004E8A3 84 C0            test        al,al
000000014004E8A5 75 1A            jne         000000014004E8C1
000000014004E8A7 48 8B 03         mov         rax,qword ptr [rbx]
000000014004E8AA 84 C9            test        cl,cl
000000014004E8AC 48 8B CB         mov         rcx,rbx
000000014004E8AF 75 05            jne         000000014004E8B6
000000014004E8B1 FF 50 40         call        qword ptr [rax+40h]
000000014004E8B4 EB 03            jmp         000000014004E8B9
000000014004E8B6 FF 50 48         call        qword ptr [rax+48h]
000000014004E8B9 0F B6 43 0C      movzx       eax,byte ptr [rbx+0Ch]
000000014004E8BD 84 C0            test        al,al
000000014004E8BF 74 AF            je          000000014004E870
000000014004E8C1 48 8B 03         mov         rax,qword ptr [rbx]
000000014004E8C4 48 8B CB         mov         rcx,rbx
000000014004E8C7 FF 50 58         call        qword ptr [rax+58h]
000000014004E8CA 48 C7 43 38 FF FF FF FF mov         qword ptr [rbx+38h],0FFFFFFFFFFFFFFFFh
000000014004E8D2 33 C9            xor         ecx,ecx
000000014004E8D4 C6 43 0D 00      mov         byte ptr [rbx+0Dh],0
000000014004E8D8 FF 15 DA 6A 08 00 call        qword ptr [1400D53B8h]

Sudden death is at 14004E8B1; registers at that point:

Code: Select all

RAX = 0000000000000000 RBX = 0000000002538CD8
RCX = 0000000002538CD8 RDX = 0000000000000000
RSI = 0000000000000000 RDI = 0000000000000000
R8  = 000000000290FE88 R9  = 0000000000000000
R10 = 0000000000000000 R11 = 0000000000000246
R12 = 0000000000000000 R13 = 0000000000000000
R14 = 0000000000000000 R15 = 0000000000000000
RIP = 000000014004E8B1 RSP = 000000000290FF30
RBP = 0000000000000000 EFL = 00010244

Stack frame can't be determined (or rather, it looks like this is the main function of a background thread).

That should help you to find out where it really dies (the map addresses don't ncessarily correspond to the load offsets in a 1:1 fashion).

[arakula]

One more:

I could get it up and running inside a VS2008 debugger now (without any command line options). Entering "E" gives the report: No network interfaces!! ... no idea how it came to this conclusion, but a missing check for this condition might be the immediate cause for the protection exception.

I could reproduce this behavior once on the command line, without debugger. Ending the program with X caused it to crash again, and each successive invocation causes it to crash after... oh,. no idea, half a second or so; obviously in a background thread, as, if I'm really fast, I can enter a command in the main thread before it crashes.

[CopperPhil]

Ok thanks a lot for all of these information. We are trying to identify the crashing line in the source code.

Can you verify the LAN network adapter properties if you see a "CopperLan over Ethernet Protocol Driver" and if it is checked?

(I'm running a french OS, but the CopperLan protocol name is the same on english systems)

[arakula]

It's there in all my more-or-less "real" Network adapters (LAN, WLAN, the VirtualBox Host-Only adapter, and a Cisco VPN Adapter).

[CopperPhil]

So, it seems that the VNM in unable to enumerate compatible Ethernet interfaces. This is normal if you run the VNM in normal mode. Since we are using raw sockets, you need to "run as administrator"... If you are able to have the VNM running into the VS2008 debuger, please try running this debugger "as administrator". So you should be able to see the interfaces thanks to the E option.

If the VNM is running well in the debugger, please start the CopperLan Manager and check the network adapter in the settings panel to see if it is matching the right one. Anyway, select done to change the current selection, then choose back the expected interface.

If no interface is found in administrator mode, please check that there is a CLoNet.clp file the CLP folder behind the folder containing CPBNM.exe.

Finally, if the VNM is running into the debugger but not as a service, first check that it is running under the System Local account. If so we need more investigation to find out how it could be possible.

I'm sorry it takes so long to find out the crash origin, it's something never met before...

[arakula]

Since we are using raw sockets, you need to "run as administrator"... If you are able to have the VNM running into the VS2008 debuger, please try running this debugger "as administrator". So you should be able to see the interfaces thanks to the E option.

Yes, in this case I see 3 interfaces.

If the VNM is running well in the debugger, please start the CopperLan Manager and check the network adapter in the settings panel to see if it is matching the right one. Anyway, select done to change the current selection, then choose back the expected interface.

OK, did that...

If no interface is found in administrator mode, please check that there is a CLoNet.clp file the CLP folder behind the folder containing CPBNM.exe.

I checked (even if it's not necessary, since it could find the interfaces in adm mode); it's there.

Finally, if the VNM is running into the debugger but not as a service, first check that it is running under the System Local account. If so we need more investigation to find out how it could be possible.

Yes, it's Local System. Do you mean that this is not the way it should be?

I'm sorry it takes so long to find out the crash origin, it's something never met before...

You should see it as a little challenge and a way to improve your product

And now - Tadaa! let's look the bright side of life:

I configured the correct interface in the CopperLan manager while CPVNM was running in administrative mode in the debugger. Then, I closed both the CopperLan Manager and CPVNM, allowed some time to pass, and then started CPVNM using the Service Control Manager. Et voilà - it came up again!

Next try: reboot the system and see whether it survives. Hummm... mmm... mmm... (why does this still have to take ages in 2012?)... mmmm.... meh... ah, a desktop comes up... done. SCM... YES! CPVNM is running! CopperLan Manager... YES! It finds the Ethernet adapter! Start virtual XP machine... YES! The two are talking again!

Looks like my immediate problem is fixed with this.

What I take from this adventure:

Obviously, when I reinstalled VirtualBox, the Host-Only Ethernet Adapter (which was reinstalled) got a new ID, which caused a glitch in CPVNM. If I upgrade again (2-3 months from now, based on VirtualBox' upgrade cycle), I'll deselect the device in the CopperLan manager before the upgrade, and re-select it afterwards.

And you should check what CPVNM does if an Ethernet device has been configured that doesn't exist any more. I have a suspicion that this is not checked as thoroughly as it should be.

[CopperPhil]

This is the best news of the day!

I was suspecting such issue, I've been hesitating to ask you to delete the registry entry storing the selected ethernet interface

So I'm happy it works now! Sure we'll improve the network adapter selection at startup to avoid this problem again!

Many thanks for your patience, your feedback was very helpful!

[Exhaumn]

TLR4 mice were associated with the greatest reduction in IH 76 decrease compared with WT mice; Figure 1D and 1E; Figure II in the online only Data Supplement <a href=https://ccialiss.top>buy crap pills</a>