[SIMS - FMS] GDI32.DLL error [Solved]

[jamesloker]

OK, FMSConnect.ini is stored in SIMS\Finance in the Program Files directory. Well i have just logged in as Administrator to windows and ran FMS, logged in as sue and still the access violation remains.

[matt40k]

Run the attached, attach the C:\permreport.txt it creates.

permreport.zip

[jamesloker]

Please find attached.

Please remember, i have added permissions in the past, they havent worked so have reverted back. Also, folders with .old are backups i have created so as not to lose any data incase of problem

Results [attachment=6805:name]

permreport.txt

Edited July 2, 2010 by jamesloker

[matt40k]

They're (GLEMSFORDSCHOOL\Staff) missing Full control of C:\windows\system32(\gdi32.dll), which is what the error is referring to.

[jamesloker]

Matt,

You didnt read my previous message. We have given full access previously, individually and to group. But i have tried again and still the access violation remains. Even if it was because of the group Glemsfordschool\STAFF that is missing. That would not explain the Administrator account experiencing the same issue. The only person who is able to access the fund review is the Headteacher. So this is not the reason as i have told CSD previously and has been noted on this thread. Back to the drawing board yet again.

[matt40k]

Did you do the whole folder?

 

It's quite clearly a permissions problem. I don't think anyone is questioning that. Now as you set up the server and used a UNSUPPORTED OS and setup, both by Capita and CSD, you've hit the problem of doing such a thing. Sounds like you've got the opportunity to bring it into support (or at least closer to it!).

 

Now if your questioning it being a permissions issue or an OS issue (ie. what you support), that leaves with data (something in the database), or the application. Now the Application is digitally signed, assuming FMSApplicationsSetup.exe has a valid digital signature, that means you have the same as everyone else, and if you've reinstalled it, that rules it out being an application problem. That make sense?

 

I can't image it'll be data, but if you want to rule that out put a FMS backup (.bak) in the Misc folder and run AnyComms and I'll test it on a spare machine. But it's extremely unlikely to be data.

[jamesloker]

Whole folder yes, and into subdirectories.

I acknowledge it will be a permissions issue, but the other issue is why did it just stop working? There was no reason for it. It has worked fine for ages.

Now as i have also said, we can use the head teacher account to view these (Fund Review and the other bit.) but why has it just stopped working. Maybe all will be resolved for September when the machine is overhauled and the new SQL 2008 is installed.

[jamesloker]

We have fixed the issue. The problem was down to a Printer Driver problem with one of our printers.

As we have 2008 server coming online, the printer driver for the Photocopiers (Infotec) didnt want to work on Windows 2003 R2 x64 (Even though i had installed that particular driver on the 2008 machine and tried the 2008 driver) The issue was caused by the Terminal Server not being able to communicate with the 2008 server for these drivers only. Our xerox and lexmark machines work fine shared from 2008 server to the 2003 box. But for some reason the drivers for the photocopiers just dont work.

Anyways the problem is solved and it ISN'T a permissions issue.

 

Hope this helps anyone with other problems similar. Try the drivers for your printers first!

 

Also, cant understand why it was bothered about the Photocopier drivers. The Xerox printer in the staffroom which is the default printer and the printer set in the printer setup in fms was working. But FMS is being picky and wanted to know about all the printers....again BAD BAD SOFTWARE!!!

Edited July 12, 2010 by jamesloker

[matt40k]

Lol!!!

[Sarconia]

Haha... all that faffling around and it happened to be a printer driver issue.

 

FMS normally has issues with printers... I'm not really too sure why it's so dependent on checking for printers before it even loads the program. I've always thought it should load regardless and then when you come to actually print, you might encounter issues... rather than being the other way round.

[jamesloker]

The work around, if anyone is interested, is to have the Photocopiers set as local printers and deployed with Group Policy on the 2003 box. Xerox and Lexmark are ok to still be deployed from the 2008 box.

[superfletch]

Thanks for this,

 

We recieved a call last week with the same error and I've been to Capita with it but the answer they gave didn't fix it.

 

We had also been going down the permissions route.

 

I'll start looking at printers now.