backendless 4.0 init .net sdk

Hi Guys

Trying to create a web sign up form in .net sdk backendless 4.0. I am referencing this sdk

I am struggling at the first hurdle which is

Backendless.InitApp(“xx”, “xx”);

catch (BackendlessAPI.Exception.BackendlessException exception) {

I am using same app pool permissions and permissions on the server as for the 3.0 app which is working.

I have this in the event viewer of server -

an unhandled access exception has occurred.

Any ideas, maybe missing something obvious?

Hi Mike,

Does the error occur if you comment out this line (trying to rule out that the problem is in Backendless).

Also, if you could create a command prompt app with the same line of code (and any subsequent APIs), does it work for you?


Hi Mark

Yes I should have said that originally, without the backendless init the page works without error.

I’m not quite sure how to do a command prompt app, but I am more familiar with a windows forms app which is easy to debug, I can try that and report back?


Hi Mike,

Whatever is easier. Visual Studio lets you create a command prompt project. This is what I usually do for a quick test.

Let me know what you find.

What version of .NET do you use?


Windows forms application works absolutely fine, so I am guessing it is some config problem with the aspx application, but I have checked the application pool and other settings for the app are the same as the 3.0 app. It does look like a permissions issue to me.

I am targeting the 4.0 Net framework.

Thanks for checking.

I see you have a try/catch block, does the exception end up there? It is interesting that ASPNET reports it as unhandled even though you’re wrapping the whole thing in an exception handler.


No it doesn’t end up int the catch block unfortunately. I only found that by looking at the server logs.

Under what user account the app pool is executing the code?

hmm Mark, you have maybe reached my limits of iis knowledge! The Identity for the pool is just ‘ApplicationPoolIdentity’ , but that might not be what you want to know?

What version of IIS is it?

Also, could you please the pdb file right next to the dll, perhaps it will give you additional stack trace info:

version 7.5. OK I’ll give that a try and report back

No difference. Will try again tomorrow with a fresh pair of eyes, thanks for trying.

Please see the following discussion:

It would be interesting to see if the behavior changes when you assign a high privileged account to your app pool.


Great article on stackoverflow, but none of the options seemed to help.

I did manage to get a proper stack trace however and I get this.

Access to the path ‘LogBufferMutex’ is denied.Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.UnauthorizedAccessException: Access to the path ‘LogBufferMutex’ is denied.

ASP.NET is not authorized to access the requested resource. Consider granting access rights to the resource to the ASP.NET request identity. ASP.NET has a base process identity (typically {MACHINE}\ASPNET on IIS 5 or Network Service on IIS 6 and IIS 7, and the configured application pool identity on IIS 7.5) that is used if the application is not impersonating. If the application is impersonating via <identity impersonate="true"/>, the identity will be the anonymous user (typically IUSR_MACHINENAME) or the authenticated request user.

To grant ASP.NET access to a file, right-click the file in File Explorer, choose “Properties” and select the Security tab. Click “Add” to add the appropriate user or group. Highlight the ASP.NET account, and check the boxes for the desired access.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:

[UnauthorizedAccessException: Access to the path ‘LogBufferMutex’ is denied.]
System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) +217
System.Threading.MutexTryCodeHelper.MutexTryCode(Object userData) +11007905
System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData) +0
System.Threading.Mutex.CreateMutexWithGuaranteedCleanup(Boolean initiallyOwned, String name, Boolean& createdNew, SECURITY_ATTRIBUTES secAttrs) +238
System.Threading.Mutex…ctor(Boolean initiallyOwned, String name, Boolean& createdNew, MutexSecurity mutexSecurity) +202
System.Threading.Mutex…ctor(Boolean initiallyOwned, String name) +49
BackendlessAPI.Logging.LogBuffer…ctor() +69
BackendlessAPI.Logging.LoggingService…ctor() +62
BackendlessAPI.Backendless.InitApp(String applicationId, String apiKey) +559
Signup.Page_Load(Object sender, EventArgs e) +31
System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) +51
System.Web.UI.Control.OnLoad(EventArgs e) +92
System.Web.UI.Control.LoadRecursive() +54
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +772

Hi Mike,

How many worker processes do you have in that ASP.NET application?

If more than one, could you set it to one and see if the problem still happens?


Hi Mark,

It has a maximum of one worker process set already (on the application pool)


Hi Mike,

The problem happens because the user whose identity is used by the app pool does not the permission to write to a temporary directory when the code creates a Mutex for synchronization. A workaround would be to grant the permission to the user:

However, a more permanent fix is on our side to rework the code to get rid of the mutex altogether. This will take a bit of time and we’re working on it.


Hi Mark

OK no problem thanks for letting me know. Could you give me a rough idea of timeline? I have a new app to release in the next week or so and I was rather hoping to go live using backendless 4.0 rather than backendless 3.0. However if we are talking months then I will have to with backendless 3.0 and then convert to 4.0 later. Unless of course I can use that workaround which I will look at next week when back to work. Thanks for chasing the cause down.



Hi Mike,

It should not take more than a week.


Hi Mark

Thank you - that timescale would be brilliant.

I did try the workaround and I really think it should have worked, but still didn’t. Do you know where the full path of ‘LogBufferMutex’ ? and I will have one more go, otherwise I will wait for you guys to rework the code.

Many thanks for your excellent support and if you could drop me a comment when you have done your changes I will start testing backendless 4.0 again.