Access Violation on compile

[[email protected]]

Hi All -

I recently purchased 5.024 PCH and PCM and installed them. I installed them into different directories, i.e. C:\Program Files (x86)\PICC-H and C:\Program Files (x86)\PICC-M. I moved the pch.crg and pcm.crg files into their respective directories. I pulled out an old project and feed it to the compiler via MPLAB. It immediately came up with "access violation" and a memory address. Both installations seem to do that.

I contacted CCS Help. They had me try the following:
1. from the start menu, I can run the CCS C Compiler version command and get it to show version info.
2. from the command line (running as administrator) tried "C:\program files (x86)\PICC-M\ccsc.exe" +fm dummy.c, but it fails.
3. CCS support had me install SYSINTERNALS (http://technet.microsoft.com/en-us/sysinternals/bb896645) to track the issue. I saved them a .csv of the calls and sent it in. They replied that `the problem shown in the CSV file you sent is the compiler attempted to open "C:\Program Files (x86)\PICC-M\dummy.ccspjt"
and your security settings on the PC prohibit that. You will either need to move your source to a directory the CCSC.EXE is allowed to write to or give CCSC.EXE admin privileges.` Same file and location works fine for the 4.124 version I have.

Anyone else have any ideas? At the end of my rope here...

[asmboy]

what version of windows?

if you use the command line compiler - on a
SIMPLE old project the result is ?

[oxo]

[[email protected]]

asmboy -

I have Windows 7.

If I execute ccsc.exe 5.024 from the command line on an old project, I'll get an access violation. If I use ccsc.exe 4.124 there is no problem.

I get exactly the same result from both versions inside MPLab X and MPLab 8.

[[email protected]]

oxo -

My project directory is located on my desktop (c:\users\kbrown\desktop) as I am logged in as kbrown. The permissions are for everyone - full control.

The ccs directory is c:\program files (x86)\picc-m\. I have set it to everyone - full control. I am running cmd.exe as administrator. What more permissions can I give it?

Note that I have an older version, 4.124, located in c:\program files (x86)\picc\. It has normal permissions (no one has full control) yet it works fine on the same source.

Could you be a little more descriptive with your response? What am I missing?

[Ttelmah]

In Windows, 'run as administrator', doesn't give administrator rights!....

You get rights based on the rights of the owner, 'anded' with those of the application itself.

However the obvious thing is what the permissions are on the folders. The PICC one was created presumably by the CCSC install, and as such will have 'users' enabled to read, write and execute files. The PICC-M one was created by you, and will have by default the combination of your rights at the time, and those on it's parent. Start by ensuring that the rights of this are the same as for the PICC folder.

Then make sure that the owner of the application is the same in each case, and has the same permissions.

Look at the 'Effective permissions' tab (right click on ccsc, and select 'properties'), then select this tab, and put in your user name. It'll display what permissions you will have when running the program.

[[email protected]]

Yeah... Umm no.

I figured it out.

It has NOTHING to do with permissions on the installed client end. It has EVERYTHING to do with directory names and drive locations.

Install the software to a machine that has never had PIC-C on it. Put it in a directory with any non-numeric/alpha character in it, i.e. c:\program files (x86)\picc-m (NOTICE THE "-", a totally legal DOS 8.3 format character). That will cause the program to throw an access violation error when run to compile a project. Rename the directory to c:\program files (x86)\piccm WITHOUT CHANGING PERMISSIONS OR DOING ANYTHING ELSE, and everything now works.

Also, there seems to be something weird with installing it on a non C: drive. It doesn't like that either.

Moral of the story - don't change the default install locations and it'll most likely work.

[dyeatman]

Interesting. I have seen users with problems using network drives as well
as ones with the access type problems TTelmah described.

I have all my compilers are installed in the directory c:\ccs_c\... with no
problems so it must be specifically the '-' character. There may be a few
more out there we don't know about.
_________________
Google and Forum Search are some of your best tools!!!!

[Ttelmah]

In Windows there are quite a few characters that do give problems. '-' is the command separator for quite a few things, so not really surprised that it can give problems. I actually assumed the poster had already tried different directory names (first thing I'd do), so ruled it out as the problem.....
Shows how you should not assume.

Other ones that will give problems:
space
/
#
:
+
=
&
{
}
!
|
$
*
'
"
`
_ (at the start)
>
<

Best Wishes

[temtronic]

hmmm..

[[email protected]]

OK all - OS wars aside, why does this work:

[temtronic]

short answer... is depending on the 'parser' that the OS is using, spaces are 'invisible' and eliminated from any further processing.

piccm is a valid subdirectory

picc-m is not a valid subdirectory

At least that's my take on why it doesn't work,it goes back to what is considered a valid character.'They' have different rules depending on root,subs,filenames, etc.

While having - signs in a filename may be OK...I don't think it's allowed for subdirectories.

I did find a couple sites that describe a lot of the nitty gritty details including LFN vs SFN and how the OS figures it out. Things got really complicated after 8.3

hth
jay

[Ttelmah]

There are three separate things happening here.

What Windows does, what the parser inside the code does, and then what Windows does to lines generated from this parser.

Now the inverted commas round the filename, prevent Windows from parsing it, so the spaces etc., are accepted. However then look at the CCS parser, and realise that it uses - as a command marker (-O -M -J). Particularly note that '-M' means 'do not create a symbol file.
So syntactically the incoming line then splits at this pair of characters, and gets parsed as something like:

c:\program files (x86)\picc
No symbol file
\ccsc.exe

etc..

KISS. There is no logical reason to stretch the bounds of what the OS/compiler supports.