Hi All,

We are having an issue with 1 of our PCs running Adagio Receivables. When trying to access a customer the user is getting the following Access Violation errors.


Error message - Click on Customer
Access violation at address 0055D9E9 in module 'Receivables.exe'. Read of address 0000002F.

Error message - Click on OK
Error reading txtYTDInvoiceAmount.NumericType: Access violation at address 0040512A in module 'Receivables.exe'. Read of address 00000000.

Error message trying to open customer.
Access violation at address 0090490E in module 'Receivables'. Write of address 00000BAF.

It is strange as no one else is having this issue. If we login to the terminal server using this user's credentials it all works fine (which is our work around). We have uninstalled the workstation setup per our dealer's suggestions and then reinstalled but not luck. In the end we are just going to replace this PC as it is due but I was interested if there might be a possible explanation for this behaviour.

Any ideas?

Thanks in advance.

Cheers,

Alex Douglas
Hoskin Scientific Ltd.

How does the user look up a customer? F5? F6? Just type in the number?

Try emptying the Windows temp directories for this user if they are using F6 (SmartFinder).

Hi Andrew,

The first error comes when the user clicks on the Customer button in the toolbar. The second comes when she hits OK to that first error. The third comes when she picks a customer.

I can try emptying the windows temp folders in an hour as she will be leaving for the day.

Cheers,

Alex

Is the user running a terminal Server session? Version of AR?

When the user runs on the terminal server it all works. When they login from their PC then it throws those exceptions. Ver 9.0C(111209)

Does the shortcut on their PC launch the same Receivables.EXE that the Terminal Server session does?

The terminal server points to "\\fremont.int.vegas.net\Adagio Program Files\SOFTRAK\Receivables\Receivables.exe"
and the local points to Q:\SOFTRAK\Receivables\Receivables.exe /uVB /dp:\hoskin\mon /eMON

I have verified that they are both the same exe as Q: is mapped to \\fremont\Adagio Program Files\

I have deleted everything from the windows\temp folder (with the exception of the Perflib_Perfdata open file) but still get the error.

Anything else to try?

Cheers,

Alex

Hi Andrew,

Just checked from OE and if you click the customers toolbar button it throws an access violation there as well but referencing OE.exe. Only from this machine though .

Alex

If you log into Adagio as another user on that machine and click the customer button, what happens?

Hi Andrew,

Tried that and it gives the same error using a different Adagio user on the same machine.

Cheers,

Alex

Alex:
If you look at Help | About on the problem computer, can you confirm it says 9.0C (111209)? What if you open Sample data from that same computer? I expect your answers will be "yes" and "same thing" but let's check.

Hi Alex,

Access Violations are generic error messages given because a process was requested to be performed by the workstation and at that instant in time it could not be.

One reason for this error is a slow connection to the data (due to the network or a large amount of data to load), or a slow workstation. To eliminate the size of data as a cause, could you try accessing the sample data company from this workstation (\softrak\receivables\samdata). If the problem does not occur following the same steps, then the workstation is having a problem loading all the required data fast enough - where other workstations and connections are OK.

If you have a copy of your company data, could you place it on your local C drive and attempt to open the copied data and try the same steps? That would eliminate the data path difference and instead focus on just the program paths you posted above. If the behaviour is the same, then the problem is related to how the data is being accessed via the path.

From your prior posts, it appears to make the problem occur, you just have to open the company data and then click on the Customer toolbar button. Is there anything else open in Receivables, or are you pressing other buttons or 'double-clicking' the customer button? You should only be single-clicking the button.

I suspect that the problem lies with the workstation itself or the connection to the server/data, which is why no other workstation is having the problem.

Hi All,

I did confirm it says 9.0C(111209).

I opened the sample data found on the network and it still through the same error.

I moved the real data to the PC locally and still got the same error.

I also moved the sample data from the network to the PC and get the same error.

The PC is from 2008 and as I have said previously it will be replaced at the end of this week. We have 1 GB Ethernet everywhere in the office.

To get this error, I simply open Receivables and click on the Customers in the toolbar. I then get the first access violation.

It did just stop working on the 8th of December so it certainly looks like the machine.

Cheers,

Alex

Sounds like a machine RAM failure at this point.

Unfortunately, we have been seeing Access Violations in many Adagio Modules, and have reported it as well. And we were told that we are the only ones seeing it. But we see at client sites fairly frequently. The fact that you are also seeing Access Violations, doesn't surprise us at all.

We see it in Order Entry, Receivables, Payables, Inventory Control, General Ledger, with Terminal Services and Lans. Now we have not had the chance to test out the experience of changing to the new hot fix of Gridview, and most of our larger sites use Gridview extensively for custom queries. Perhaps that will help, and here's hoping it will.

In Order Entry, we can make it occur on demand, on both XP's and Win7. We have seen on many client networks, and our own. So I'm not buying the RAM Failure or or the network failure anymore either. Not to say that a defective PC or NIC or Cabling or Switch is not a possiblity, but I have my doubts.

We simply shut down the workstation and try again, or reboot. We have removed and reinstalled software applications to no avail. We will start to monitor again to see if the frequency goes down now that we are installing the recent GV Hot fix. We'll keep you posted.

Brian

Well Brian, can you suggest a better answer than a hardware problem given the following?

• It only happens on this machine.
• It doesn't happen when running a Terminal Server session.
• It started happening without any other change to the machine.

Access violations occur when a program attempts to read and/or write to memory not under its control. This can be the result of a program bug or hardware problem. Most access violations are harmless (although annoying), so we just report the error and continue, rather than halting the application, which we believe would be more disruptive. They will never go away entirely, as they can be created by race conditions in very specific hardware environments. Perhaps we should stop reporting them on the screen and simply log the occurrence in a file? However, that will mask problems that should be fixed, so I'm not sure it makes a lot of sense.

Perhaps you'd care to share the steps that can create this problem "on demand" with Steve and/or our Technical Support department as they have been requesting? The easiest way would probably be to record a video and send it to us using Jing.

Following up on this topic. The new machine arrived and we used the Windows Transfer Utility to move the user's profile over. This same error showed up on the new machine. We then created a new profile and did workstation setups and the error was not there anymore. Therefore the error must have been in the profile on the original machine. I have had to rebuild profiles on other machines before but I didn't even think of doing this as it looks like Adagio runs primarily from a network drive.

The new machine is working fine with the new profile so there is no immediate need to find a solution. I still have the old machine so I would like to test any ideas to see if we can't get to the bottom of the problem. Knowing that it is integral to the user's profile is a big step and will help us troubleshoot these types of problems in the future but I would like to entertain any possibilities as to what file/folder/registry setting is the culprit.

Thanks,

Alex Douglas, P.E.
Hoskin Scientific Ltd.

What "user profile" are you referring to?

The windows user profile.

Hmm - I've not known anyone to use the Windows migration to set up a user on a new machine. At Softrak, we always set up a new machine from scratch.

My guess is that there is a rights issue on the permissions of the old profile.

I would like the rights issue too except all of our users are setup as administrators of their own machines. This was done historically so we wouldn't have any of those kinds of issues but likely should get changed going forward.
We typically setup new users from scratch as well but in this case we wanted to move the profile over to verify that the issue was hardware related to the old machine and not software related. We have now determined that it isn't hardware related and the problem lies in the windows profile itself. Of course this machine was working fine for many months until something went wrong. We did look through the windows event log just before it stopped working properly but there was nothing that stood out.
Anything we can look at or test on the machine itself?

Well, where is the WINDOWS\TEMP (and TMP) directory? Are they running Adagio on the machine of which they are an Administrator, or are they using a Terminal Server session for their Adagio work? Do they have full rights to all the Adagio Folders? Are they all signing in with different Adagio User ID's? Do people ever sign on from different workstations with the same Adagio ID at the same time? What other applications do they run? Do the profiles load the same startup applications? Are their "trusted sites" profiles the same? Any one and/or all of these are involved in the regular operation of Adagio.

At an Adagio site, every user should:

• Be an Administrator of their own machine.
• Have a separate TEMP path from all other users.
• Log in with a different Adagio User ID.
• Have all rights to the Adagio data space and all sub Folders.
• Make sure that they exit Adagio normally before logging out or powering down or disconnecting their station.

If you can find a Windows utility that will dump the User profile to a report, you could try printing out the two and comparing the settings to see what's different. Perhaps there's even a Regional Settings option that has been changed. If you find anything let us know.

Andrew:
Andrew:
This client has done this same thing in the past. Leigh helped me out with the same problem in their Vancouver office in late November on a workstation. They copied over the complete profile from an old workstation to the new workstation (i.e Windows and network login script). Leigh came in online and we went through several scenarios before finding the problem. This was the second time it happened in Vancouver office. I have tried telling them in the past to contact me regarding Adagio setups but IT guys like to save time and do copyovers. I am currently looking into problem with Leigh and will have her let you know outcome.