Mark Yedinak

Ok, I realize it has been a while. I had to put this on the back burner for a while. Anyway, I finally resolved the problem. Turns out that the key file was encrypted and the application web server couldn't read it. I had to do various conversions using openssl so I could get a key file that was not encrypted. Now it is finally working. It had been a couple of years since the last time I did this and I had forgotten that crucial piece of information. What a pain in the butt.

Yes. The entire process I used to create the CSR and get the certificate was the same. I used OpenSSL to generate the CSR, sent that to my CA (same as before) and got the new certificate. I followed the steps in the KB I linked earlier and so far nothing has worked.

Yes, it is the key used for the CSR to generate the certificate.

Yes, it was in the same folder as I am putting the new certificate in.

Well the error is not very detailed. The previous certificate that worked was from the same certificate authority and the info was the same. I'm still trying to find the magic combination to get the application web server to accept the certificate.

This is the error log I am seeing: appweb: Error: OpenSSL: Cannot define private key file: C:\ProgramData\National Instruments\certstore\server_certs\server_0.key I am trying to add my external certificate. I had done this a couple of years ago but forgot the exact combination of steps that worked back then. I have tried creating a CSR from the web server config and then adding my certificate as the correct certificate. This hasn't been working. I also tried to replace the self signed certificate with mine. This is very frustrating. As I did mention, the certificate itself is fine. It works for the NI Web Service as well as for an apache server running on a Linux machine. I just can't get the Ni Application Web Server to use it.

The NI Application Web Server. I specified that in my original post. No, there is nothing in the trace. I finally found some log information. I was looking in the Program Files (64 bit) shared folder but the logs are actually in the 32 bit folder. I am getting an error opening a certificate that is in the certstore folder but is not actually referenced anywhere. I think this may be the issue and I will dig into this some more. This particular application is still on LabVIEW 2018. I know that there have been some improvements with respect to certificates in more recent versions but at the moment I cannot update.

I have an externally signed certificate for TLS that I am trying to install to replace an expired certificate. I have followed the process described here. Everything appears to work but when the application web server is restarted so it will pick up the new certificate I see that the certificate has disappeared. The files are still there but when looking at the application web server info in the ancient Internet Explorer interface the certificate is gone. I have enabled logging for the application web server but I never see any entries in the log file. This had worked in the past but now nothing is working. BTW, the certificate works fine as the NI System Web server uses it and everything works as expected. The certificate is also used on a different Linux based web server (it is a wildcard certificate for my domain). I would like to get this certificate installed and working. Anyone have any suggestions? I should also note that in the race instances that the certificate still appears in the Ni Application Web Server configuration (via the Internet Explorer interface) any attempt to invoke a connection using TLS is rejected immediately. A trace using Wireshark shows the connection is accepted and the Client Hello message is received from the client then the connection is immediately closed with a TCP-RST by the server. All of this had worked properly in the past. The only difference is that I am installing a new certificate since the old one expired. This certificate is valid since it works with the NI Web Server as well as a Linux based Apache server.

I took a look at JSON and I definitely like it better than XML. The problem in this particular case is that I will have binary data as part of the data set and JSON doesn't look like it supports that very well. I will probably just define the data format using a basic C style structure and decode/encode it in LabVIEW.

Is the variant data type well enough defined that a specification can be given to programmer's using another language that they could decode/encode variant data? I am working on a messaging interface that will pass messgaes between LabVIEW, Python and possibly C/C++. Obviously within LabVIEW variants are a very convenient way to pass generic data around at the lower levels of a messaging API. However, the format of the data when flattened to string to pass over TCP connectons is rather daunting. Is my best option to change my lower level code to use a more conventional and defined data structure (basic a simple stream of bytes) and then parse that ino meaningful constructs in LabVIEW? That is, where I currently have variants should I replace them with a string and then at the appropriate places decode that into a cluster. Taking this approach would allow me to define C style structures which can be easily read/transmitted in other languages.

Count me in. Just bought my ticket. And you can tick the CLA count too.

No, The data collection loop is running at a whopping 1 sample per second. The display and logging tasks are driven by the collection tasks. That is what is so baffling about this leak. This application is running at a very slow pace and to see the increase in handles and memory over a short period of time is quite surprising. I will be digging into this more later. I don't think I'll get a chance to work on it today though. Thanks to all for the suggestions.

OK, I haven't broken the application down into the component parts yets but did rebuild it on my local machine (this application actually runs at a client site) and monitored it overnight. The memory is slowing increasing and the stats from perfmon shows that the handle count is extremely high. The handle count was well over 7000000 after about 6.5 hours of running. The memory size was 5 times greater than when the application started. It is colecting the data from a remote site using HTTP once per second. It then logs that same data into a DB. Both the HTTP connection and DB connection are left open. Does the extreme handle count provide any clues where to look. I will break it into three separate applications for test purposes but thought the handle count may point to a specific area.

And no, no DLL's that I know of. If the password protected stuuf is calling something though I would have no way of knowing.

The beauty of user events is that you effectively get a one to many queue. Notifiers are one to many but can only contain the lastest data. User events will queue up th eevents like a queue but the sender only needs to generate a single event to broadcast it to many parts of the application. Queues on the other hand are many to one. To get a broadcast message either the lower level code has to know everyone who will get the message or you implement some middle man task to receive the message and post it to the queues for everything (publish and subscribe) interested in getting it.

This would probably work. I think I would try this with the HTTP and DB tasks. I suspect it is one of those causing the issue and not the UI task. My first inclination is the DB task but there isn't much there on my end and the tollkit VIs are password protected so it is hard to say what they are doing under the hood.

Yes, I do realize it is very difficult to give advice without the code. Anything in particular to look at with the dynamic registration? I have two sets of user events that the tasks register. One is what I call application events that are general events like start, stop, exit, etc. The other is application specific events which as the name appies is events specific to this application. I use an AE for each set of the events and separate VIs to actually post the specific events. The events only get registered once in each of the tasks. Your idea abouth separating the tasks is interesting but I would need to have some different method of passing the messages between them if they were separate applications. the events would not pass application boundaries. Without the messaging only the data collection task would actually do anything. The other two are acting on messages out of the collection task.

I am running into an issue with a memory leak. Due to NDA I cannot post code. The issue is have is that the deployed exe has a memory leak yet I do not see it when running in the IDE. The code is fairly basic and consists of three tasks. The first task is a basic UI event task and it does updates two strip charts during execution. The second task is a data collection task that retrieves data from a device using HTTP. The third task is a data logging task that writes the data to a database. Messages are passed between the tasks using dynamic events. Each task is basically a while loop with an event structure. Tasks two and three are subVIs on the top level block diagram. I have scoured the code for any unitialized shift registers or run away arrays. Tasks two and three both open their connections (HTTP and DB) once and use the same connection throughout the execution. Error processing will open a new connection is there is an error but it will cleanup the old connection. Also, I have not recorded any errors so they application should be using the original connections it opened. The DB stuff (using the database toolkit) is executing stored procedures. It does free the resources for each transaction. I have run the execution trace tool (not on the built exe), profiler and VI analyzer and nothing is jumping out. Any ideas on how to isolate what is causing the memory leak? As I stated the leak only exists in the built exe. Running in the IDE shows memory usage to be very stable. I am running out of places to look. Any thoughts or ideas would be appreciated. (Sorry about the lack of code, but I'm not at liberity to post it.)

I will have to look at the application instance specifics. To answer your questions though, we are using a custom process model, we are deploying this as an exe and we do ensure that we keep the development environment/run-time engine settings in synch. When we deploy TestStand is set for the run-time enviroment. We have seen cases where it would work in the development environment but not the deployment. In the past we had asked NI about sharing a queue from the GUI to TestStand. We were told it was not possible. This was why we opted for a network based solution. We did find a solution to this issue. Our messaging libraries had been using a single client queue to post messages to our message server (network based). The problem with this was that TestStand and LabVIEW could not share that queue. Our message class orignally only provided for a single quueue reference. Our solution was to allow it to manage multiple queue references. This all happens internally to the class. As a result we had to create an initialize method for our messaging class which would provide a unique "client ID" for it's messaging. Calls to the post message method simply needed to use the "client ID" when posting messages. The message class manages the various client queues and everythign is working now. Everything is neatly bundled up and if our messaging class is used in a single application the client ID is not necessary, therefore nothing special has to be done to use the messaging class.

We have confirmed with NI that the memory space is not shared between the LabVIEW GUI (application which starts and controls the TS sequence) and the TS sequence. The queues we are using pass the data over the network so that is not the issue. We can pass data. The issue that we have is our generic messaging system is using a functional global to hold the queue reference and unfortunately this FG does get shared by the GUI and the TS side. However, neither side can use the other's queue reference. We need a very generic method to obtain a unique ID of some sort that can be derived programmatically. This value would need to be consistent within the confines of the GUI or the TS side of things yet be different from each other. Our current approach using the application name and process ID does not work since this is the same for both instances. In addition, I don't want this method to assume the presence of TS. It has to be TS agnostic. Some thoughts I had would be something along the lines of a thread ID. Though I am not sure this would work since I can't find a way to get that value and I believe that NI's scheduler can place the execution on different threads which would not guarantee uniqueness across multiple calls. This solution cannot use a wired in value since these message objects are several levels deep in the library code as well as being used within different libraries. We have already tried the owning application reference thinking this may be unique but it isn't.

I have run into a bit of a problem and wonder if anyone has solved this or knows of a solution that will work. We have an extensive library of reusable LabVIEW classes that we are utilizing both or automation framework GUI and TS sequences. A part of these libraries is a generic application messaging systems that is based on a networked based queue. Our messaging classes are self contained and designed to not require any external input. They use internal data for references to the queues. The problem we have encountered is that in our application the GUI and the TS sequence actually share different application space and cannot share a reference to a queue. We need a method to programatically determine which memory space we are in. We would use this information to do a look-up for the correct queue reference. We do provide an initialize method for our messaging class which will create the queue and store the reference. We need a way to get a unique identifier based on the memory space it is running in. This method needs to be generic and not assume we are running in a TS environment. The process ID and application name will not work since both the GUI and TS sequence will share this. Any ideas on a workable solution?

Well, the solution I posted earlier worked fine when adding a single line of text but fell apart if data was added in chunks. Here is the latest and greatest method for achieving what I wanted.

I will have to look at that. If it uses a standard library in the LabVIEW distribution I can modify the code to use that. The problem with an llb file is that it uses absolute paths which can cause problems when using source code control. I would like to avoid that issue hence my desire to break the VIs out and add them to a lvlib file instead.

Does anyone know the password for the GetSocketInfo VI in the above library? I would like to make my own library with several other functions. I would like to use the new lvlib format instead of the llb format. However, the one VI is password protected and therefore I cannot add it in any other library.

Thanks Ravi, but your simplified VI does not accomplish what I wanted. As I have stated I want the auto-scroll to keep the scroll bar position at the end of the display as new data comes in. HOWEVER, if the user moves the scroll position up I want to disable the auto scrolling until the user moves the scroll bar pointer back to the end position. And this has to work with data that does not have actual lines. The data my be what is effectively extremely long strings of arbitrary and possibly binary data with no carriage returns or line feeds. The solution I posted above mostly accomplishes this. In the actual application I will be using it I have found a case where I am unable to re-enable the auto-scrolling when I move the pointer back to the bottom.