PrestoSoft Community

ExamDiff Pro v3.3 locks up when 'compare' window is shown with invalid UNC folder (e.g. \\BOGUS\MyShare). It doesn't even give me a chance to change the incorrect path; the programs locks up indefinetely and can't even be killed by TaskManager (Windows XP). Other than this problem, i've really enjoyed using ExamDiff.

thanks

I don't see it happening in 3.3 or 3.4 Beta. When I enter \\BOGUS\MyShare in the Compare dialog, I get the following error message on pressing Compare button:
Are there any other steps involved?

I get the same error message. How does explorer react if you feed it the bogus UNC? I have known programs (including explorer) hanging indefinitely after network resources become unavailable, but not if they never existed.

Your correct. The remote folder existed at one time, but is no longer available (remote computer was turned off, etc). In my specific case, I use Exam Diff to update remote computers that I reach via a VPN. So not only is the computer not reachable, but the network is not reachable either when the VPN is not connected.

This is still a huge problem for me - I can't even run ExamDiff without it totally locking up. It makes ExamDiff (which I need to use a lot) completely unusable . Any fix in the next version would be greatly appreciated.
thanks.

It's hard to reproduce such problem but I think it must Shell APIs (that EDP uses) that hang, not the program itself (not that this is much help for you). I still didn't see your answer to zweinstein's question:

How does explorer react if you feed it the bogus UNC?

To add a little to the mystery, I must admit that after posting my diagnosis, I spotted a few unresponsive EDP taksbar icons. I think they were comparison windows already open before I started experimenting (even though Change Notification is always Do Not Monitor). I didn't give them more than 5 minutes or so. They offered no resistance to Windows 2000 task manager's kiss of death. After that I was unable to reproduce them.

Note that EDP seems to remove traces of crimes committed. Whether you cancel or exit after clicking away the error message, the history lists of first and second files and directories do not record the bogus paths. This is good, we don't want typos leading nowhere to clutter the history lists. However... after wildly playing around with multiple instances, several bogus paths are in my history now - in fact file comparison defaults to one. I say wildly because I failed to get any bogus path stored in history when following a reproducable sequence of starting and closing EDP sessions. What is going on here?

zweinstein's question

Oink!

In response to 'How does explorer react if you feed it the bogus UNC?':
It varies, sometimes it immediately tells me that the path is invalid, other times it hangs for several minutes, other times it hangs forever.

Its understandable that if I type in a bad address and hit Compare that EDP might hang for a while. But once that invalid UNC is the default, then EDP hangs when I first start it without even giving me a chance to change it.

My workaround for now is to always used mapped drives instead of UNC paths. EDP doesn't seem to have problem with mapped drives that are no longer valid.

However... after wildly playing around with multiple instances, several bogus paths are in my history now - in fact file comparison defaults to one. I say wildly because I failed to get any bogus path stored in history when following a reproducable sequence of starting and closing EDP sessions. What is going on here?

I'm not sure. It's obviously hard to tell without knowing your steps, but wouldn't be "wildly"...

I'm also confused whether or not EDP froze/delayed for you when you used an invalid UNC path in the Compare dialog. Regardless, perhaps the following link will shed some light on the problem: http://www.sysinternals.com/blog/2005/0 ... oying.html

So you are saying that EDP hangs (indefinitely?) even before you get a chance to change a name, right? In other words, when you start EDP, it doesn't show up (indefinitely?), correct? If so, it sounds odd: nothing, as far as I can seen, in EDP code goes to verify file/directory existence when the application starts. Perhaps I'm missing something here.

BTW, is there a way to reproduce this problem outside of working with VPN?

On my system, the bogus default path doesn't cause any delay when starting EDP from the Start menu, not does selecting another bogus path from the history. There is no problem, only the odd fact that bogus paths are sometimes remembered but not when you look closely.

aaronp, what if you circumvent the selection dialog, e.g. select 2 files in Explorer and Compare them from the Explorer menu?