"Unable to execute file for security reasons" with protected UID

[rjmu]

hi,

My app consists of two exes, one is XXXSrv.exe which runs in background with mobile starting, another is XXX.exe.

Previously I tested the app with two unprotected UID, in range 0xA..., assigned to two exes seperately. The app worked on emulator, no *PlatSec* warning. And it also worked on mobile with my Developer Certificate signing.

Last week we were going to Express Sign the app, and protected UID needed. So I replaced two unprotected UID with two protected UID, in range 0x2...

When I signed the app with the same Developer Certificate, the app can be installed on mobile without error. And the backgroud exe XXXSrv.exe runs as expected. But XXX.exe throw an error msg "Unable to execute file for security reasons" when starting.

Could someone kind to explain why it's OKAY with unprotected UID, but failed with protected UID?

Some backgroud:

1. I'm sure I replaced every UID correctly, because I've replaced with another two unprocted UIDs and it worked.
2. On emulator there are no PlatSec warning.
3. I searched the forum and googled it, but no help. Many of them said it's because of using some capability not specified in mmp files. But it's weird here that it actullay worked with unprotected UIDs.
4. my developer certificate is valid.

Any help is greatly appreciated.

[symbianyucca]

that error should come only when there is a capability missing, so do re-check your codes and the mmp file. Also it could help if you could check (maybe with logging) which line is giving this particular error when you execute your application in the device.

[rjmu]

Thank you, symbianyucca.

that error should come only when there is a capability missing, so do re-check your codes and the mmp file.

But symbian does not check capability of the apps with unprotected UIDs?

Also it could help if you could check (maybe with logging) which line is giving this particular error when you execute your application in the device.

I am going to see where it stops with logging. It seems to be the last action I could take

[symbianyucca]

Capabilities are always checked, also with self-signed applications, thus I'm assuming that you did some other change which you just didin't notice on causing the problem..

[rjmu]

Yes, there's a bug I did not notice. It was found with very verbose logging.

the following code will result different string with UIDs which are larger than 0X80000000 and with UIDs smaller than 0x80000000, because the first arg of AppendNum is interpreted as TUInt64. And unprotected UIDs happen to be following into the former case and protected UIDs the later.

TBuf<32> tmp;
tmp.AppendNum(KAppUid.iUid, EHex);
path.Append(tmp.Mid(8));

Changed to the following code, and the problem resolved.

TBuf<32> tmp;
tmp.Format(_L("%x"), KAppUid.iUid);

Thanks

[wizard_hu_]

I doubt that contents of descriptors (obviously created in runtime) could really affect if the application can be started at all.
Anyway, because of your variable 'path', you may want to check RFs::PrivatePath.

[rjmu]

My original implementation will result to a wrong path c:\private, and accessing it is forbidden. c:\private\2000AAAA is what I want.

RFs::PrivatePath is much better. Thank you.