In Lookout 6.5, new Windows 7 Computer running server process file stops allowing clients to connect over time

[JPhillips]

 I just installed a new Dell T3500 32-bit workstation running Windows 7 Pro as my Lookout server. When I initially open my server file, clients are able to connect as I can see in my client connection panel. Over time no new clients are allowed to connect, and if I close Lookout on one of the clients that are connected, when I reopen Lookout on the same client it cannot connect to the server computer. I am able to ping the server (IP or computer name) from all clients even though the clients will not connect to Lookout on the server. Once I reboot the server, all clients are then able to connect. Also, windows firewall is not running on server or any clients (disabled by our network administrators)

Please give me some ideas on how to resolve this ASAP.

Thanks.

Jason Phillips 

[JPhillips]

The clients lost their connection to the server again this morning twice in a couple of hours, and the second time it happened when I closed the server file and then reopened it, I got an error saying "Process Registartion Failed".

Is there something in Windows 7 that would be affecting the NI License Manager?

Again, I am able to ping my server from any of the clients when this problem happens.

Thanks.

[JPhillips]

A couple of more notes:

This new computer I am running my server file on has 6 processors as opposed to 4 processors on my previous computer running my server file. I do know that when I went from a single processor computer to a dual processor computer, this same type of behavior occured and a patch had to be written for Logos. Is it possible that this behavior is caused by the fact that I have six processors? Is anyone running Lookout on a computer with six processors?

Also, when I have to restart the server file due to know clients being able to connect, the only way I can get it to open is by killing the lkads service and then starting Lookout. If I start Lookout without killing the lkads service first, Lookout will not open.

I need this issue resolved ASAP.

A quick response from NI would be greatly appreciated.

Jason Phillips 

[Ryan.S]

I suggest you to try a workaround.

Open the NI All User folder.

C:\Documents and Settings\All Users\Application Data\National Instruments on XP

C:\Users\All Users\National Instruments on Win7

Create a folder named Logos

Create a file named logos.ini in Logos folder.

In the ini file, input

[logos]
Global.DisableLogosXT=True

Do it on both server and client computers. Restart Lookout.

I guess the problem is in the Logos communication.

[JPhillips]

I tried this workaround when I upgraded from 6.2 to 6.5 and it worked:

http://forums.ni.com/t5/Lookout/Lookout-6-5-clients-not-connecting-to-server/td-p/1136874

So, this workaround was already implemented. Plus, the behavior I am seeing now is different than what was being caused by LogosXT (I had many CLOSE_WAIT messages when running netstat with the original problem - not seeing that with this problem)

While I was typing this response to you I had my client file running on my laptop and I was remotely watching task manager on the Windows 7 computer running my server file. When I clicked on one of my panels in my client file, I noticed I had no trends on this panel. I then started clicking on other panels and realized I lost all of my trends. I was still getting updates from my server, but my trends were gone.

I then looked at task manger on my server file and could see that nicitdl5 service was stopping. I have it set to restart after 1 minute if it fails, but every time it would restart it would then fail 5-10 seconds later. Once I saw this, I went back to my client file and could see that I was still getting updates, just no trends, which meant my symbolic link connection was still fine.

So, I then closed my client file and reopened it - RED Xs everywhere. For whatever reason, when this nictdl5 service problem arises as long as I don't close my client file I keep my symbolic link connection, but if I close my client file and then reopen it OR open a client file on a machine that wasnt running a client file when the nictdl5 service began failing, I do NOT get my symbolic link connection back.

The only way to reestablish my symbolic link connection and get my nictdl5 service running correctly is to close my server file, stop lkads service, and then reopen my server file.

I decided to set lookout.exe to run in Windows XP SP3 Compatibility mode and see if the problem occurs again.

I will let you know.

If you have any other ideas, please let me know.

Thanks for the response Ryan.

[Ryan.S]

As you already implement this workaround, I suggest you to remove it and try again. This workaround is not a fix, but just disabling the LogosXT(a different protocol from Logos). The LogosXT might not work correctly in your previous case, so I asked you to disable it and see if it worked. But actually it should not have problem. So, can you remove this workaround? Let's test the original environment without any fix or workaround.

The problem is probably in the Logos communication, not the lookout.exe. So I don't think it will have any difference after you change the lookout.exe running mode.

[JPhillips]

Ryan,

Now that Tropical Storm Lee is past us, I can continue to try and get this issue resolved. Constant failures by nictidl5 and lkads resulted in numerous restarts restarts/reboots in order to keep lookout running through the storm.

Prior to the storm, I enabled LogosXT again as you suggested, which resulted in the same behavior I experienced the first time I moved from 6.2 to 6.5, so I disabled it again.

My lkads,exe version is 5.1.0.49153 - is this the most recent version? 

My nicitdl.exe version is 5.7.0.49152 - is this the most recent version?

Again, the only thing that has changed since this problem arose is the operating system (from WinXP to Win7) and, of course the computer hardware (as I stated earlier, the new computer has 6 processors as opposed to 4 in the older computer).

In doing some research on Windows 7, I noticed when you go to share a folder, there is an advanced box you can bring up that states "maximum simultaneous users" and the max you can put in is 20. Now, I have more than 20 clients who are running the web client version of Lookout and have to access a certain folder on the server when they open the web client. Does this 20 simultaneous user max affect Lookout clients accesing the web client folder on the server?

Thanks for any assistance.

[JPhillips]

Ryan,

I've also noticed in Windows 7 (unlike XP), when nicitdl5.exe fails, I have it set to restart after 1 minute. But every time it restarts it fails shortly thereafter and continues to do this over and over again. The only way I can get it to work correctly again is to close my Lookout file and reopen it.

In XP, to solve my issue with my cliects randomly losing there trends, I created a batch file which would stop nicitdl5.exe once and hour - by doing this my clients were practically never without trends. Unfortunatley, I cannot do this now because of the problem I just described.

Below is the error information from Windows 7:

Crash info from Application Log (4 messages):

Faulting application name: nicitdl5.exe, version: 5.7.0.49152, time stamp: 0x4a3a95a4
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc000001e
Fault offset: 0x00251098
Faulting process id: 0x1c90
Faulting application start time: 0x01cc6bd2eadd0e6d
Faulting application path: C:\Windows\system32\nicitdl5.exe
Faulting module path: unknown

Windows cannot access the file  for one of the following reasons: there is a problem with the network connection, the disk that the file is stored on, or the storage drivers installed on this computer; or the disk is missing. Windows closed the program Citadel Services because of this error.

Program: Citadel Services
File:

The error value is listed in the Additional Data section.
User Action
1. Open the file again. This situation might be a temporary problem that corrects itself when the program runs again.
2. If the file still cannot be accessed and
 - It is on the network, your network administrator should verify that there is not a problem with the network and that the server can be contacted.
 - It is on a removable disk, for example, a floppy disk or CD-ROM, verify that the disk is fully inserted into the computer.
3. Check and repair the file system by running CHKDSK. To run CHKDSK, click Start, click Run, type CMD, and then click OK. At the command prompt, type CHKDSK /F, and then press ENTER.
4. If the problem persists, restore the file from a backup copy.
5. Determine whether other files on the same disk can be opened. If not, the disk might be damaged. If it is a hard disk, contact your administrator or computer hardware vendor for further assistance.

Additional Data
Error value: 00000000

Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: nicitdl5.exe
P2: 5.7.0.49152
P3: 4a3a95a4
P4: StackHash_0a9e
P5: 0.0.0.0
P6: 00000000
P7: c000001e
P8: 00251098
P9:
P10:

Attached files:

These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_nicitdl5.exe_e7fd12eeb13a399e626913b5fb703e21ade09b_1a300b5b

Analysis symbol:
Rechecking for solution: 0
Report Id: 363434db-d7c6-11e0-81bb-bc305bd124f8

Report Status: 4

Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: nicitdl5.exe
P2: 5.7.0.49152
P3: 4a3a95a4
P4: StackHash_0a9e
P5: 0.0.0.0
P6: 00000000
P7: c000001e
P8: 00251098
P9:
P10:

Attached files:

These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_nicitdl5.exe_e7fd12eeb13a399e626913b5fb703e21ade09b_1a300b5b

Analysis symbol:
Rechecking for solution: 0
Report Id: 363434db-d7c6-11e0-81bb-bc305bd124f8

Report Status: 0

[Ryan.S]

So, the Citadel service crashes. I want you to create a memory dump on the crash.

When the nicitdl5.exe crashes, do you see a popup dialog box? If you see it, don't close that dialog box, and open the Task Manager, right click on the nicitdl5.exe and select to create the dump. It's a built-in feature in win7 that it can create the memory dump without other tool.

But if you don't see the pop-up dialog box, you may use a tool to generate the dump.

Here is a blog about it.

http://blogs.msdn.com/b/cobold/archive/2010/03/01/collection-crash-dumps.aspx

You need to download the WinDbg SDK from microsoft website. And follow the steps in Section What to do when the crashing process will be started in the future.
After you add the key to the registry, the WinDbg will generate the dump file automatically when any application crashes.

[JPhillips]

Ryan,

Sorry for not responding back sooner, but I think I solved the issue yesterday around lunch time thanks to resource monitor in Windows 7. Once I stumbled on to this program I kept it running and when the problem occurred I noticed 2 instances of nicitdl5.exe running and when one terminated the other one started and back and forth they would go until I shut down Lookout. However, in task manager all I would see is one instance of nicitdl5.exe starting and then failing over and over again as I had mentioned in an earlier post.

I think my problem was that the 30 second time span I had used in windows XP between starting and stopping the nicitdl5.exe service every hour was too short in Windows 7. I say this because since I increased the time span to a minute between starting and stopping this service, everything has been running great (around 30 hours now). I have not lost trends and have had no crashes.

I figured I might have an issue or two when going from XP to Windows 7, but nothing this minor that caused such big problems!

Thanks for your help and hopefully you will not hear back from me as far as this issue is concerned.