Logging stops with "Invalid Signature"

[gregg]

Hello-

Win10, sCRT v8.3.2 (x64 build 1584)

I've recently started trying to log to a network drive via unc \\server\path\file.log

and have on occasion noticed a dialog hiding in the background saying:

Unable to write log file:
\\server\path\file.log
Invalid signature.
No more data will be logged.

afaik, there has been no network interruption or other issue preventing writing.

I think the biggest issue is that this error dialog does not come to the front, so lots of logging is possibly lost before noticing the dialog.

Also, the file menu still shows a check mark next to Log Session, which seems to indicate that a log is in process, even though it's not.

What does "Invalid Signature" mean in this context of logging?
Can Secure CRT have some sort of retry mechanism?
At the least, bring that dialog to the front?

Thanks!

ps. i'm really enjoying some of the features, such as split panes and solarized color schemes!

[bgagnon]

Hi Gregg,

What does "Invalid Signature" mean in this context of logging?

I do not know, I am not familiar with that error.

It would seem it might be related to this info.

Can Secure CRT have some sort of retry mechanism?
At the least, bring that dialog to the front?

Certainly I can create the feature requests but let's see if we can determine the cause of the issue first.

Also, the file menu still shows a check mark next to Log Session, which seems to indicate that a log is in process, even though it's not.

Is that how you are enabling logging? Via File->Log Session? (If not, just flip the first two inquiries below.)

• Does this only happen with the File->Log Session method?
  
  
• Do you get the same results if the log file is specified in the session? (Terminal / Log File category of Session Options)
  
  
• Does this work if specifying a log file on a local drive? (just want to make sure it is a share-related only error)
  
  
• What OS is running on the share?

[gregg]

Hmm, it is possible that it's related to that MS KB you linked because the remote host is FreeNAS (FreeBSD based NAS) running Samba for the shares. I'll review that avenue a bit more.

> "Is that how you are enabling logging? Via File->Log Session?"

It is not, all of my sessions have "Start log upon connect" and "Append log" along with a filename of:

\\bucket\software\Internet\VanDyke\scrt\logs\%Y%M%D-%S.log

I will try using File->Log session and see how that goes.

Separately, I will also try logging locally, though I suspect that will be fine.

[bgagnon]

Hi Gregg,

That specific phrase (invalid signature) did not appear anywhere in our bug reporting database, so I do think it might be related to the share itself.

I did add this thread to a feature request in our product enhancement database to prevent dialog boxes from displaying under main SecureCRT application window (or display the info in terminal window). Should a future release of SecureCRT include this feature, notification will be posted here.

If you prefer direct email notification, send an email to support@vandyke.com and include "Feature Request - Forum Thread #13139" in the subject line or use this form from the support page of our website.

In this particular scenario, I don't know if the "retry" would make sense if it would only continue to fail. And the only other cause I can think of off the top of my head, such as not having write permissions, would mean the user would need to intervene. I'm still happy to create the feature request if you want it though.

[gregg]

Hi Brenda- Thanks for the responses and avenues to check.

In this particular scenario, I don't know if the "retry" would make sense if it would only continue to fail.

Just to clarify, logging does happen initially, at some point the dialog comes up and logging stops.

Secure CRT menu still thinks that logging is happening because it shows the check mark. To restart logging, I have to File->Log Session (so that scrt stops logging even though it is broken at this point). And then immediately do File->Log Session again so that it restarts logging.

Getting curious, I've also started sysinternals procmonitor and procexplorer.

I thought I would also try logging to a mapped drive, so S:\path\file.log, but noticed somewhere along the line it gets converted to \\unc\path according to procmon.

In any case, I now have the suspicion that after the error, the file remains open, just unused. (This coincides with the check mark next to File->Log Session) But I will need to wait for the error to occur again to check some things.

[bgagnon]

Hi Gregg,

I did create a feature request on your behalf to retry logging when it fails. Have a great weekend!