I got a bug that seems to prevent me from opening any file. I updated to the latest version (I think I was on v2.6.0 and had just updated to v2.6.3).

I couldn't open files from the File>Open menu. I couldn't open files from the recently opened menu. I couldn't drag files in from Windows Explorer. I tried resetting my settings to factory defaults but still nothing happened.

When I dragged stuff in, sometimes the mouse cursor would turn to the "loading" circle, but then nothing would happen. When I tried dragging in 3 files at once, I got the "would you like to merge your files" popup, and if I said "yes" nothing would happen.

I pulled up Task Manager and it didn't seem like LogViewPlus was using any reasources, no RAM and no CPU, so it wasn't busy trying to parse my files...

I also tried re-opening LogViewPlus as an admin, but that didn't change anything.

There seems to be some files I can open. Specifically, I was able to open recently used logs in a sub-folder inside my Downloads folder. But the vast majority of files I couldn't open no matter where they were (Downloads, Downloads/randomFolder, Desktop, Desktop/randomFolder)

I tried reinstalling version 2.6.3 and still had the issue. I tried turning off DirectX just to see if it would help but it didn't change anything.
My last step was uninstalling 2.6.3 and downloading and installing 2.6.0, and that worked!

So I'm up and running now, but if I had to guess there might be a bug in the new release? I know one of my coworkers mentioned they had an issue like this but I hadn't had time to talk to them to see what was going on, but perhaps they're on the latest version and had the same problem?

If it would help, I can make a little screen recording simulation. Or if there are log files I can grab for you to see what's going on, let me know. I am quite sure this isn't a problem with my parsers, since I tried multiple different file types without success.

Thanks for the detailed bug report. I can see that you have tried a number of different approaches - that really helps.

I will see what I can do to recreate it locally, but it may be difficult.  We do quite a bit of testing before releasing across a number of different machines and I have not yet seen this issue.  I wonder if there might be something unusual about your local machine?  From your description, this sounds like a pretty straight-forward use case.

The other thing we can do is review the code to compare 2.6.0 and 2.6.3.  This might help narrow down the areas that might be causing a problem.  However, this will take some time.

I will post back as soon as I have reproduced or been able to narrow the issue down.

Thanks again,

Toby

I have reviewed the code.  There are a lot of changes between 2.6 and 2.6.3, but nothing is jumping out as a possible issue.

What version of Windows are you running?  This release improves Windows 11 support and upgrades the common library to 4.7.2.  These changes should not be causing issues, but it is possible.

I have also uploaded the 2.6.1 beta and 2.6.2 beta releases.  If possible, could you test with 2.6.2 and then 2.6.1 to see if you are able to recreate the issue?  Knowing the version where the issue was introduced may help with tracking it down.

Thanks,

Toby

I have a potentially similar problem with 2.6.3: I can open local files just fine, but a network file does nothing, regardless of whether the file is in an open share (no security) or via the admin access (e.g. \\Machine\C$). The same network file will open with Notepad++ and other editors just fine using all the methods I mention.  All other network functionality is up and running as normal.

Things I have tried:
1. Run as Admin: no change.
2. Open from file menu in LogViewPlus: Won't open.
3. Drag-and-drop: won't open
4. Double-click on file: won't open.
I downloaded the betas you posted and both exhibit the same behavior. I also don't think this is a credentials issue unless your app has issues accessing them on my machine that other apps do not.

My system:
Windows 11 - strongly suspect as it is the only major change of software/hardware in use.
Files are on a Windows Embedded 7 machine - don't think this matters as it worked fine with LogViewPlus for years.
Wired network.

Happy to help test in any way I can. Your product is a critical part of my debugging process and I use it daily.

Thanks for reporting this issue.

We had a very similar issue with opening files over a network share reported a few weeks ago.  In that case the user was able to resolve their problem by running LogViewPlus as Admin.  As you are only having problems with a network share, your issue may be a separate problem to the one discussed above.  The issue raised by Memnarch seems more generic.

I have just tested locally from a Windows 11 network share as well as a Windows 10 network share.  In both cases, I was unable to recreate the issue locally.

One thing that is clear is that we need to improve our error reporting for the next release.  I will definitely look into this, but I would prefer to implement a fix.  It is difficult to do so without being able to recreate or narrow down the problem.  Unfortunately, I do not have a Windows Embedded test machine.

In the meantime, the only work-around I can suggest is downgrading to a prior version or copying the file locally.

Hope that helps,

Toby

I'm seeing this issue as well.  My machine is Windows 10 Enterprise 21H2.  Files are all network shares.  I usually don't have a need to open anything locally, so everything I tried wasn't working.  I can try to find out the OS these file shares are running if it would help.
I just tried a couple of local files.  I was able to open a log file for an application inside my appData\Local folder and a file inside my Downloads folder.  It failed to open a log file for a program inside C:\Program Files.  I cannot open this file when running LogViewPlus as admin either.

For now, I'll downgrade to 2.6.0, but I'm willing to help test if needed.

Thanks Chris - that's a big help!

I tested in my local Program Files directory and I believe I was able to recreate the issue.  Just prior to the 2.6.1 release we modified one of our URI validation steps.  The new version is URI escaping, so 'Program Files' becomes 'Program%20Files' which doesn't exist.  LogViewPlus does not consider this an error because sometimes log files do not exist for one reason or another so the application fails silently (these types of decisions need better visibility).

This is likely to be the root of the problem that everyone is experiencing on this thread.  If you are having issues with a path that does not contain spaces, or other characters that need to be URI escaped, then please let me know.

As this is a critical issue we will try and get a release out as soon as possible.  I will look into creating a BETA release tomorrow.

Thanks for your help everyone! 

Toby

Hello everyone.

I suppose, I am experimenting with the same issue: if the path name contains space symbol, LVP just ignoring it.
You can see the issue and fixing on the video in attach.


https://www.youtube.com/watch?v=DBr68MeCGK4LogViewerPlus v2.6.3 don't open file with "Space" symbol in path

And I have a big-big request to LVP developers: please show error notifications.
In any suspicious and irregular case, please show error messages.
Especially if LVP just ignoring user action, at least, explain why.

By the way, where is LogViewerPlus storing its own logs?

Thanks Andrii.

Yes - that does look like the same issue.

We are on it:



We are aiming to have a BETA release later today.

Toby

"Workspace issues" is coooooool! 
Thank you!
I'm waiting for the new update.