Lookout Exe high memory usage

[iwanhoo]

Thank you for a reply.

Can you help me with reading the log file? Regarding the latest crush, where are the important spots in the log file?

What's the meaning of the following few rows?

*----> Stack Back Trace <----*

WARNING: Stack unwind information not available. Following frames may be wrong.

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\system32\GDI32.dll - 

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\system32\USER32.dll - 

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\system32\ntdll.dll - 

*** WARNING: Unable to verify checksum for C:\Program Files\National Instruments\Lookout 6.1\lkworks.dll

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Program Files\National Instruments\Lookout 6.1\lkworks.dll - 

Ivan Krantic

UNO-LUX Processing 

[Ryan.S]

lookout.exe is the main application of Lookout. lookout.exe calls the lkworks.dll to make lookout run. lkworks.dll is the main dll of Lookout.

When lookout prints the panel, it needs to call the windows interface, because the printer is handled by the windows. Lookout actually doesn't talk to the printer directly when it prints the panel.

These codes in the log file are the "call stack". It tells you what files are called from the beginning to the end. The ntdll.dll, user32.dll and gdi32.dll are all windows DLL files. Lookout calls the windows interface in the windows dll, and the windows DLL calls the printer's driver finally.  The crash happens in the printer's driver DLL file. 

By the way, the log file has the crash information, however the crash memory dump was not logged. The dump file is still the last SQL crash. I don't know why the memory dump was not logged. Maybe you can try to delete the current dmp file.

But even if we had the dump file, we could not do anything since we don't have the source code of the printer driver. If the crash happens in the printer driver and the memory dump is logged successfully,  the printer provider is able to look into the dump file.

[iwanhoo]

Thank you for such a detailed answer. The customer suggestion is to install Debug Diagnostic 1.1 so we can track the processes.

What's your opinion about that?

Ivan Krantic

UNO-LUX Processing 

[Ryan.S]

The Debug Diagnostic is a debug tool from Microsoft. You can use it to track the performance of lookout, including the crash/hang/memory leak. After a crash, it is able to generate the memory dump file too.

It's a same kind of debug tool as Dr. Watson.

[iwanhoo]

Hello Ryan,

We tried the following. Copy all database files to new folder, and backup the database (in parallel). Then, delete the old data files and archive the copied files into old database. And archive the base that we backup into the old database. Each time we lost the last two weeks of data. Why is that?

Ivan Krantic

UNO-LUX Processing

[Ryan.S]

I don't understand why you copy the database files to new folder, delete the old database files and then archive the database in new folder back to the old database.

I don't suggest you to manually copy the database files when it is logging. If Citadel is logging data to a file, you may fail to copy that file because the file is being used. You can copy the database files when the logging is stopped, or the database is detached.

Before you copy the data, make sure the last two weeks of data is in the old database. After you copy the files, create/attach the database in new folder, and check if the last two weeks of data is in the database. Take a look at the database each time when you copy or archive the database, and then we will know if the data lost is a result of copying or archiving.

[iwanhoo]

We had another Lookout crush. This is the message it displays. I will try to get dump file and then i will upload it if you can help us again.

Can migration to Lookout 6.5 solve the problems we have?

Regards

Ivan K.

[iwanhoo]

This is the last dump file. But I think that there is no report for the last crush here.

Ivan K.

[Ryan.S]

The crush was not catched in the dump file...

I remember that there was a crush when you tried to archive the database, and then I suggested you to use a new database. Have you already been using a new database? The old database can be a backup database. If you need some historical data, you can archive last two weeks of data from old database to new database. I want to make sure the logging database is not so large and the data in it is good.

Although we fixed some bugs in Citadel, I cann't say that your problem is related to a bug in Citadel database.

[iwanhoo]

What we have done:

Archived the old database into a new one, and delete entire database. Then archive back the data so the base is the same, but the data was deleted then restored.

So, in version 6.5 the citadel version is also new? I saw that nicitdl5.exe file is the same.

Ivan K.