I have a serious issue trying to read folders and files on a machine tool running Win95.
This issue is new due to moving Dopus to a new HP Z820.
Whilst Explorer appears to function reasonably satisfactorily, Dopus all but refuses to view beyond 2 folders.
Lots of Not Responding.
Whilst an HP XW8600 performs this task pretty much seamlessly, the HP Z820 all but refuses to do so.
The requirement is to read and write simple text files.
Thanks
Geoff Hansen
You're trying to run Opus 10.5.0.5 x64 on Windows 95?
No Leo, I am trying to read the win95 files... via the network... from Dopus on the Z820.
Thanks
Geoff
So you've got Opus on two machines (XW8600 and Z820) and you're trying to read files from a network drive shared from a third machine (running Win95), and Opus is working OK on one machine but not on the other machine?
Are you using the same Opus configuration on both machines?
Is the network drive mounted in the same way on both?
Any differences in things like the type of antivirus installed on the two machines?
Hi Leo,
Line 1 - Yes
Line 2 - Yes
Line 3 - Yes .... No antivirus on the Z820.... the machine I am having trouble with.
Thanks
It's difficult to guess, in that case. If the Opus version & configuration is identical on the two machines, and they're accessing exactly the same network share, mounted in the same way, and the same files on it, then there must be some other difference between the machines, or with the network/firewall/etc., which is causing things to fail. (Otherwise they would fail on both machines.)
The Crash, exit or high CPU usage when viewing certain directories guide may have useful suggestions in tracking down what is failing when the folder loads, particularly if it is due to a 3rd party shell extension that is only installed on one of the machines.
Process Explorer may also be useful for investigating where things are failing (although it is quite a technical tool).
It may also be worth updating to a newer version of Opus, since 10.5.0.5 is a bit old now and was also a beta version.
Hello Leo,
Just a wee update as to what has been happening since our last communication.
I have had the local HP support people heavily involved.
We are finding the same result on a number of HP machines regardless of version.
HP support will in the next few days email me some graphs and info related to the problem.
We believe it is a DOpus issue.
I take it I can attach files and emailed info to this interface ?.
Will be in touch.
Thanks
Geoff Hansen
You can attach things in the full post editor. Click "post reply" or "full editor" rather than "quick reply".
Hello Leo,
Result from HP,
Hi Geoff,
Following from the day spent diagnosing and testing your application problems, all 4 x z820 production machines (yours plus the 3 units I bought to test), suffer the same application errors and subsequent extreme delay in accessing the Index lathe via Directory Opus. Also worth noting that both the 8770w and 8780w mobile workstations suffered the same problems - in fact the only platform which provides consistent speed is the xw8600 workstation and the early z820.
I have attached the performance monitoring graph and hardware summary taken from your z820 (which is also indicative of all the other z820 machines tested). Of particular interest is the extreme local disk activity. Given Directory Opus is a small application and the resource being browsed to is on the network, I am at a complete loss as to why there would be sustained disk activity of 70-100% (hardware specification including disk controller also attached).
Having ruled out faulty hardware by virtue of the number of different machines and platforms we have now tested on, I am left believing there is an compatibility issue with the application and drivers or OS. As I have not had a chance to test earlier versions of Directory Opus, I cannot ascertain whether the reason for the application running fine on the xw8600 is in fact because of it being an early version of Directory Opus installed with upgrades applied as opposed to an installation of the current version.
I recommend you provide this information to the Directory Opus team to see if they have had any similar experiences, or can confirm incompatibility with hardware platforms used in these tests.
Should you require any further information or assistance, please contact me as below.
Regards
Carl Hansen | Market Development Manager – Workstation, Thin Client & RPOS| PPS | Hewlett-Packard NZ Ltd
22 Viaduct Harbour Ave, Maritime Square, Auckland, NZ | Mob: +64 21 566 479 | Tel: +64 9 918 9475 | Email: carl.hansen@hp.com
Note: This email (including any attachments) is intended only for the use of the individual or entity named above and may contain information that is confidential, proprietary or privileged. If you are not the intended recipient, please notify HP immediately by return email and then delete this email, destroy any printed copy and do not disclose / forward or use the information contained herein.
Don't know if the attachments are in fact attached Leo.... Screen just goes full page, and have had to "Back Arrow" to add this line.
If the team wish to access my computer via WebEx to see just what's going on, I could download and install this program.
Thanks
Geoff
No attachments came through, sorry. Under the full post editor, you need to click the "Upload attachment" tab, then click Choose File, then click Add the file once you have chosen it. If you use the Preview button you can see if a file is attached or not.
My guess is you have a shell extension installed on the machines with the problem, as part of another piece of software, and it is getting involved when Opus reads the folders in question (or possibly any folders with similar file types). That, or something like an antivirus scanner, are the most likely causes of large amounts of local disk access when accessing a remote share, since there aren't many reasons Opus would do that on its own.
If you can get logs using Process Monitor, that would be best as its logs can show which DLLs are involved in the activity, which can pinpoint things like shell extensions, antivirus, drivers, etc. which all run inside of unrelated processes. (Process Monitor will also show which files are being accessed, which is often a big clue as to what is accessing them and why.) If the existing logs/graphs only show percent CPU/disk usage then they won't tell us anything useful.
It also doesn't really make sense to keep testing with an old beta version of Opus. Is there any reason you're still using that particular beta version and have not moved to a stable version? (10.5.1.0 and 10.5.2.0 have both been out for a while now.)
Hi Leo,
I think we might have got 2 files attached.
We have tried fresh install of windows 7 by way of HP restore.... several times.
To this fresh build, we add DOpus, then try communicating. .. Doesn't matter which version of software, the result on this machine is the same.
I will however update this machine this morning.
Thanks
Geoff
That graph doesn't tell us much, as I feared.
I would use Process Monitor to get some proper logging (as discussed just above), and also maybe try some other tools which list directories on the same path to see if they get similar delays and it's just Explorer (which includes File Open dialogs etc.) which isn't showing the delay. (e.g. The dir command from a Command Prompt is a good thing to try, since it's built into Windows but doesn't use Explorer to get the list.)
Hi Leo,
Have downloaded Process Monitor as requested.
You will now need to advise the use thereof and what I need to look for.
thanks
Geoff
Load Process Monitor, reproduce the problem in Opus, then save the process monitor log via its file menu.
Use the PML format for the log, and zip up the file it outputs.
Hello Leo,
Just tried to send you a file, however I think it was too big.
If I am lucky I may be able to get the file I am trying to read an around 3 minutes.
However the data collect in this timeframe is rather large... I will "run" the problem for a few seconds and then save the file you asked for.
Thanks
Geoff
(Thanks! I've removed the attachment after downloading it, to keep the details private since it reveals some (usually unimportant, but not always) info about the machine/software/etc. --Leo)
The log shows Avast is running on the Z820.
I can't see any significant amounts of reading or writing data to files on the local drives, from what's in the log at least.
The main thing which stands out is a lot of activity via the csc.sys and rdbss.sys drivers, which are to do with remote storage and client-side caching. (If the remote data is being cached locally, that could account for the disk activity while accessing the remote drives.) Those two drivers both have a few bugs logged against them in different Windows versions, so it may be worth checking that the Z820s have the latest Windows service packs installed.
Looking at where Opus gets a directory listing for the Index drive, there's only really this (repeated three times at different points in the log):
(You may need to make your browser quite wide to see the whole image. Keep going until you run out of white background.)
Is that the complete list of files and folders you would expect to see below those directories?
Are there things missing from the list in the screenshot?
Or are there things in the screenshot which are not showing up in Opus? (The problem isn't just that Opus is configured to hide some files/folders and they're being hidden, is it?)
