All of a sudden I started getting the typical Structure Map error stating, "No parameterless constructor defined for this object". This is a common error and usually means that something is wrong with the object being injected. In my case, the object being injected did not change nor anything pertaining to the config, Nuget packages, etc. The object being injected simply uses Windows Azure Storage Nuget package for managing blobs. Why all of a sudden is this getting this error?
Unfortunately, this took a bit of my time but I finally got this to work and here were the steps.
Commented out the code in the injected objects constructor...Error disappeared
Uncommented the first line of code below and received the ERROR again.
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(
CloudConfigurationManager.GetSetting(AppSettingName));
Changed the above line of code to below and everything started working.
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(
ConfigurationManager.AppSettings[AppSettingName]);
Punched myself in the face a couple of times wondering what the devil went wrong with original code deployed in Azure is working!
Related
When I recreate my VM I got the following error:
Problem occurred during request to Azure services. Cloud provider details: Unable to edit or replace deployment 'VM-Name': previous deployment from '8/20/2019 6:20:33 AM' is still active (expiration time is '8/27/2019 5:17:41 AM'). Please see https://aka.ms/arm-deploy for usage details.
Help me please to understand.
What could be the cause of the error ?
UPDATED:
This deployment has not been started previously.
Prior to this, errors were received during creation:
Azure is not available now. Please Try again later
There were several such errors one at a time and then I got that error related to:
Unable to edit or replace deployment
My assumptions about this.
Tell me, am I right or not ?
I launched the image, then after some time I recreated it.
Creation began, but at that moment the connection with Azure was lost.
Then, when the connection was restored, we tried to make a deployment that was not removed in the previous attempt (because there was no connection with Azure).
As a result, we got such an error.
Does this theory make sense?
exactly what it says, there is another deployment with the same name going on at this time, either change the name of the deployment you are trying to queue or wait for the other deployment to finish\fail
This can also occur if you use Bicep templates for your ARM deployement and multiple modules or resources in the template have the same name:
module fooModule '../modules/foo.bicep' = {
name: 'foo'
}
module barModule '../modules/bar.bicep' = {
name: 'foo'
}
I got the same error initially pipeline was working but when retriggered pipeline took more time so i canceled the deployment and made a fresh rerun it encounters. i think i need wait until that deployment filed.
Azure Functions bug. I get the error in the portal
Error:
We are not able to retrieve the runtime master key. Please try again later.
Session Id: d13fceebd4ea4cb1b7fb3d3829dd1406
Timestamp: 2017-08-24T20:04:23.555Z
I've tried all of the suggestions here:
https://blogs.msdn.microsoft.com/jpsanders/2017/05/09/function-app-error-we-are-not-able-to-retrieve-the-runtime-master-key/
I'm using the runtime version 1.0.10917 but I've tried ~1 and get the same result.
This seems to occur when I delete the function from the portal and then recreate it. It consistently happens after that for every function we have. The first time the function is created, it seems to work.
This is the exception you're hitting
System.Security.Cryptography.CryptographicException : The payload was invalid.
at Microsoft.AspNetCore.DataProtection.Cng.CbcAuthenticatedEncryptor.DecryptImpl(Byte* pbCiphertext,UInt32 cbCiphertext,Byte* pbAdditionalAuthenticatedData,UInt32 cbAdditionalAuthenticatedData)
at Microsoft.AspNetCore.DataProtection.Cng.Internal.CngAuthenticatedEncryptorBase.Decrypt(ArraySegment`1 ciphertext,ArraySegment`1 additionalAuthenticatedData)
at Microsoft.AspNetCore.DataProtection.KeyManagement.KeyRingBasedDataProtector.UnprotectCore(Byte[] protectedData,Boolean allowOperationsOnRevokedKeys,UnprotectStatus& status)
at Microsoft.AspNetCore.DataProtection.KeyManagement.KeyRingBasedDataProtector.DangerousUnprotect(Byte[] protectedData,Boolean ignoreRevocationErrors,Boolean& requiresMigration,Boolean& wasRevoked)
at Microsoft.Azure.WebJobs.Script.WebHost.DataProtectionKeyValueConverter.Unprotect(Key key) at C:\azure-webjobs-sdk-script\src\WebJobs.Script.WebHost\Security\DataProtectionKeyValueConverter.cs : 43
at Microsoft.Azure.WebJobs.Script.WebHost.SecretManager.ReadHostSecrets(HostSecrets hostSecrets) at C:\azure-webjobs-sdk-script\src\WebJobs.Script.WebHost\Security\SecretManager.cs : 383
at async Microsoft.Azure.WebJobs.Script.WebHost.SecretManager.GetHostSecretsAsync() at C:\azure-webjobs-sdk-script\src\WebJobs.Script.WebHost\Security\SecretManager.cs : 83
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at async Microsoft.Azure.WebJobs.Script.WebHost.WebJobsSdkExtensionHookProvider.GetOrCreateExtensionKey(String extensionName) at C:\azure-webjobs-sdk-script\src\WebJobs.Script.WebHost\WebHooks\WebJobsSdkExtensionHookProvider.cs : 71
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.Azure.WebJobs.Script.WebHost.WebJobsSdkExtensionHookProvider.GetExtensionWebHookRoute(String extensionName) at C:\azure-webjobs-sdk-script\src\WebJobs.Script.WebHost\WebHooks\WebJobsSdkExtensionHookProvider.cs : 64
at Microsoft.Azure.WebJobs.Extensions.EventGrid.EventGridExtensionConfig.Initialize(ExtensionConfigContext context)
at Microsoft.Azure.WebJobs.Host.Executors.JobHostConfigurationExtensions.InvokeExtensionConfigProviders(ExtensionConfigContext context)
at Microsoft.Azure.WebJobs.Host.Executors.JobHostConfigurationExtensions.CreateStaticServices(JobHostConfiguration config)
at Microsoft.Azure.WebJobs.JobHost.PopulateStaticServices()
at Microsoft.Azure.WebJobs.Script.Utility.CreateMetadataProvider(JobHost host) at C:\azure-webjobs-sdk-script\src\WebJobs.Script\Utility.cs : 362
at Microsoft.Azure.WebJobs.Script.ScriptHost.LoadCustomExtensions() at C:\azure-webjobs-sdk-script\src\WebJobs.Script\Host\ScriptHost.cs : 670
at Microsoft.Azure.WebJobs.Script.ScriptHost.Initialize() at C:\azure-webjobs-sdk-script\src\WebJobs.Script\Host\ScriptHost.cs : 510
at Microsoft.Azure.WebJobs.Script.ScriptHost.Create(IScriptHostEnvironment environment,IScriptEventManager eventManager,ScriptHostConfiguration scriptConfig,ScriptSettingsManager settingsManager) at C:\azure-webjobs-sdk-script\src\WebJobs.Script\Host\ScriptHost.cs : 937
It's very hard for users to discover these errors for their app because the runtime doesn't log them anywhere the UX can query.
This issue is tracking the exception: https://github.com/Azure/azure-webjobs-sdk-script/issues/1832
We are still not entirely sure why this is happening. Did you republish your keys from another application by any chance? (edit: or delete and recreate the app with the same name) these keys are encrypted by a function app specific key, and won't work outside that context.
fix: copied from Fabio Cavalcante
can you delete (or rename) the host.json file in
d:\home\data\Functions\secrets\ and retry? This will force the runtime
to re-create those secrets for that environment. Keep in mind that
this would also change your master and default keys.
Switching the Azure Function storage account to a new storage account can trigger a similar issue.
Error: We are not able to get the key swaggerdocumentationkey.
Please check the runtime logs for any errors or try again later.
This is likely related to the storage account being uninitialized with the new site. I can't confirm the behavior, but it seems that when switching storage accounts the new account doesn't initialize a new site and will cause similar issues.
i deleted the azure functions and renamed it. After that it started working fine. Looks like even when you delete the azure functions, traces are there in azure logs and screwing up something.
Also make sure you keep separate azure blob storage for every functions, if you use it in more than one azure function, then it is giving some weird errors. I think they are using it for logging and authentication purposes.
I am having problems getting the Microsoft.Azure.Documents library to initialize the client in an azure worker role. I'm using Nuget Package 0.9.1-preview.
I have mimicked what was done in the example for azure document
When running locally through the emulator I can connect fine with the documentdb and it runs as expected. When running in the worker role, I am getting a series of NullReferenceException and then ArgumentNullException.
The bottom System.NullReferenceException that is highlighted above has this call stack
so the nullReferenceExceptions start in this call at the new DocumentClient.
var endpoint = "myendpoint";
var authKey = "myauthkey";
var enpointUri = new Uri(endpoint);
DocumentClient client = new DocumentClient(endpointUri, authKey);
Nothing changes between running it locally vs on the worker role other then the environment (obviously).
Has anyone gotten DocumentDb to work on a worker role or does anyone have an idea why it would be throwing null reference exceptions? The parameters getting passed into the DocumentClient() are filled.
UPDATE:
I tried to rewrite it being more generic which helped at least let the worker role run and let me attached a debugger. It is throwing the error on the new DocumentClient. Seems like some security passing is null. Both the required parameters on initialization are not null. Is there a security setting I need to change for my worker role to be able to connect to my documentdb? (still works locally fine)
UPDATE 2:
I can get the instance to run in release mode, but not debug mode. So it must be something to do with some security setting or storage setting that is misconfigured I guess?
It seems I'm getting System.Security.SecurityExceptions - only when using The DocumentDb - queues do not give me that error. All Call Stacks for that error seem to be with System.Diagnostics.EventLog. The very first Exception I see in the Intellitrace Summary is System.Threading.WaitHandleCannotBeOpenedException.
More Info
Intellitrace summary exception data:
top is the earliest and bottom is the latest (so System.Security.SecurityException happens first then the NullReference)
The solution for me to get rid of the security exception and null reference exception was to disable intellitrace. Once I did that, I was able to deploy and attach debugger and see everything working.
Not sure what is between the null in intellitrace and the DocumentClient, but hopefully it's just in relation to the nuget and it will be fixed in the next iteration.
unable to repro.
I created a new Worker Role. Single instance. Added authkey & endoint config to cscfg.
Created private static DocumentClient at WorkerRole class level
Init DocumentClient in OnStart
Dispose DocumentClient in OnStop
In RunAsync inside loop,
execute a query Works as expected.
Test in emulator works.
Deployed as Release to Production slot. works.
Deployed as Debug to Staging with Remote Debug. works.
Attached VS to CloudService, breakpoint hit inside loop.
Working solution : http://ryancrawcour.blob.core.windows.net/samples/AzureCloudService1.zip
I am getting a System.AccessViolationException thrown during the execution of an Azure Web Role (run on the Azure emulator, this has not been uploaded to Azure yet) when a call is made to an overridden method of an object when a local int variable is passed as one of the method parameters. The exception message is "Attempted to read or write protected memory. This is often an indication that other memory is corrupt".
The code where the exception is thrown is part of a local library that has been used for several years on live systems (not Azure) with no issues. The part that errors is as follows:
foreach (XmlDataComponent item in this.items)
{
int index = 0;
XmlNode node = item.ToXml(dataSet, xmlDocument, this, index); // Exception thrown when this call is made
...
}
The XmlDataComponent is a base class, when the code runs item is one of its derived classes. The ToXml() method is overridden in the derived classes. The exception is thrown as soon as the call is made to ToXml().
The problem is the index parameter. If I swap this to use an explicit value instead of the local variable, e.g.
item.ToXml(dataSet, xmlDocument, this, 0)
there are no errors.
Similarly, if I cast the item to its actual type e.g.
((XmlDataItem)item).ToXml(dataSet, xmlDocument, this, index))
and mark the ToXml() method in the XmlDataItem class as new instead of override there are no errors.
I have also tried calling the library from a console application rather than a web role with exactly the same data (i.e. everything the same other than running under a web role). Again, this caused no problems.
It appears that when run under the Azure emulator, accessing a local variable as a parameter to an overridden method is an issue!!!
I'm hoping this is only an issue when run under the emulator, however we still need a fix otherwise dev is more difficult.
Any suggestions or advise would be much appreciated.
I've been running a cloud drive snapshot in dev for a while now with no probs. I'm now trying to get this working in Azure.
I can't for the life of me get it to work. This is my latest error:
Microsoft.WindowsAzure.Storage.CloudDriveException: Unknown Error HRESULT=D000000D --->
Microsoft.Window.CloudDrive.Interop.InteropCloudDriveException: Exception of type 'Microsoft.WindowsAzure.CloudDrive.Interop.InteropCloudDriveException' was thrown.
at ThrowIfFailed(UInt32 hr)
at Microsoft.WindowsAzure.CloudDrive.Interop.InteropCloudDrive.Mount(String url, SignatureCallBack sign, String mount, Int32 cacheSize, UInt32 flags)
at Microsoft.WindowsAzure.StorageClient.CloudDrive.Mount(Int32 cacheSize, DriveMountOptions options)
Any idea what is causing this? I'm running both the WorkerRole and Storage in Azure so it's nothing to do with the dev simulation environment disconnect.
This is my code to mount the snapshot:
CloudDrive.InitializeCache(localPath.TrimEnd('\\'), size);
var container = _blobStorage.GetContainerReference(containerName);
var blob = container.GetPageBlobReference(driveName);
CloudDrive cloudDrive = _cloudStorageAccount.CreateCloudDrive(blob.Uri.AbsoluteUri);
string snapshotUri;
try
{
snapshotUri = cloudDrive.Snapshot().AbsoluteUri;
Log.Info("CloudDrive Snapshot = '{0}'", snapshotUri);
}
catch (Exception ex)
{
throw new InvalidCloudDriveException(string.Format(
"An exception has been thrown trying to create the CloudDrive '{0}'. This may be because it doesn't exist.",
cloudDrive.Uri.AbsoluteUri), ex);
}
cloudDrive = _cloudStorageAccount.CreateCloudDrive(snapshotUri);
Log.Info("CloudDrive created: {0}", snapshotUri, cloudDrive);
string driveLetter = cloudDrive.Mount(size, DriveMountOptions.None);
The .Mount() method at the end is what's now failing.
Please help as this has me royally stumped!
Thanks in advance.
Dave
I finally got this to work last night. All I did was create a new container and upload my VHD to it so I'm not sure if there was something weird going on with the old container...? Can't think what. The old container must've been getting a bit long in the tooth..!?!
2 days of my life I'll never get back. Debugging live Azure issues is an excruciatingly tedious process.
It's a shame the Azure CloudDrive dev simulation doesn't more closely replicate the live environment.
One source of the D000000D InteropCloudDriveException is when the drive (or snapshot) being mounted is expandable rather than fixed size. Unfortunately, the MSDN documentation provides minimal information on restrictions, but this note is an excellent source of information:
http://convective.wordpress.com/2010/02/27/azure-drive/
I can confirm Dave's findings regarding the BLOB container (Love you Dave, I only spent one evening).
I also had problems debugging before changing BLOB container.
The error message I had was "there was an error attaching the debugger to the IIS worker process for url ...".
Hope this helps some poor Azure dev, having a challenging time with the debugger.