07-26-2011 08:20 AM
Hey Vix -
I'd like to be able to reproduce what you're seeing here. Could you please post some code that reproduces what you're seeing so that I can investigate?
Thanks -
NickB
National Instruments
07-28-2011 01:11 AM
The code is the one I posted in Message 4 of this discussion.
I'll try to write a simple example reproducing the problem, but I'm not sure because it seems to be very computer-specific.
I think it's related to the interactions between:
09-19-2011 09:22 AM
Hi Nick,
good news!
I have a small example that replicates my problem (at least on my Win7 64-bit CVI 2010 SP1 machine) - see attachment
With a step-by-step debug I saw in NI Distributed System Manager 2010 that all the variables are properly created, but when I start the process, they're deleted!!!!!! ...and so the following CNVCreateBufferedWriter() gives an error.
I hope this helps finding a solution.
09-20-2011 10:58 AM
Hey Vix,
I could not reproduce this issue with your code. Is this running as a startup app, or under any special conditions?
09-21-2011 12:58 AM
As I wrote in one of the previous messages, I think this problems only happens under special conditions:
I don't know if the reason is in one of them, or the problem is some kind of interaction.
This is the situation:
09-26-2011 01:08 AM
I've already written in one of the previous messages: I think it could be difficult for you being able to reproduce this specific behavior, but I'll do my best to help you sending some other debug info from my machine.
Tell me what can I do, because this problems is really annoying and frustrating (believe me)
09-26-2011 05:23 PM
The Shared Variable Engine uses ports 5000 and 6000 by default. Could you check to see if either of those ports are blocked by your security software? Also, maybe Outlook is also trying to use those ports. You could call "netstat -an" from the command prompt without the shared variable engine to see if port 5000 or 6000 is being used. If that is the case, I can provide you instructions on how to change those ports.
09-27-2011 01:30 AM
The Shared Variable Engine uses ports 5000 and 6000 by default. Could you check to see if either of those ports are blocked by your security software?
I don't know. I'll ask to my system administrator
You could call "netstat -an" from the command prompt without the shared variable engine to see if port 5000 or 6000 is being used.
Immediately after the boot, I stopped "National Instruments Variable Engine" through Control Panel >> Administrative Tools >> Services, then I call "netstat -an".
There are some connections related to these ports:
TCP 0.0.0.0:5151 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5357 0.0.0.0:0 LISTENING
TCP [::]:5357 [::]:0 LISTENING
UDP 0.0.0.0:5000 *:*
UDP 0.0.0.0:5002 *:*
UDP 0.0.0.0:5003 *:*
UDP 0.0.0.0:5355 *:*
UDP 0.0.0.0:6000 *:*
UDP 0.0.0.0:6004 *:*
UDP 0.0.0.0:6005 *:*
UDP 10.1.2.16:5353 *:*
UDP 169.254.249.185:5353 *:*
UDP [::]:5355 *:*
Is this information helpful?
09-27-2011 10:14 AM
It looks like something else is taking ports 5000 and 6000 before your application can. Maybe this is a race condition and occasionally your application beats it to those ports which explains why it works some of the time. Let's try changing the ports of the shared variable engine.
In the system registry, add the following two keys:
The two keys don't exist by default, so you probably need to create them. The two keys should be DWORD values. By default the FirstClientPort is 5000, so make this something that is not taken like 5001. And FirstServerPort is 6000 by default, so let's make that 6001. Then resart the system and try your application again.
09-27-2011 10:31 AM
Unfortunately I don't think this is the reason of my problems because (without having modified the registry yet):
but CNVCreateBufferedWriter() returns the usual error
Anyway tomorrow morning I'll do what you suggest me and other tests, and I let you know.