【Azure Function App】Nodejs Function遇见WorkerProcessExitException : node exited with code -1073740791 (0xC0000409) 错误

简介: 【Azure Function App】Nodejs Function遇见WorkerProcessExitException : node exited with code -1073740791 (0xC0000409) 错误

问题描述

Nodejs Function,使用Blob Trigger用于处理上传到Storage Blob的文件,但是最近发现偶发报错:Exception while executing function: Functions.AzureBlobTrigger ---> Microsoft.Azure.WebJobs.Script.Workers.WorkerProcessExitException : node exited with code -1073740791 (0xC0000409)

 

问题解答

根据错误消息的编码[-1073740791 (0xC0000409)],查到错误消息为 STATUS_STACK_BUFFER_OVERRUN,称栈缓冲区溢出异常,说明系统在此应用程序中检测到基于堆栈的缓冲区溢出。

从此错误中可以判断中,报错与函数在执行时所占用的内存大小有关,经过对成功和失败处理的结果对比,最终发现是触发函数的Blob文件大小相关。

  • 当上传文件小于50MB时,函数执行正常。
  • 当上传文件大于50MB时,函数异常退出。

但是,根据对Blob Trigger的描述分析,它本身并没有对文件的大小由任何限制,所以无法通过修改配置/参数的方式缓解问题。同时,函数的后端实例的内存大小也是可能导致出现  STATUS_STACK_BUFFER_OVERRUN -1073740791 (0xC0000409) 的因素之一。  

 

最终,在没有好的办法之前,通过限制Blob 文件大小的方式临时缓解。

 

参考资料

Function App的并发和内存使用情况:https://learn.microsoft.com/zh-cn/azure/azure-functions/functions-bindings-storage-blob-trigger?tabs=python-v2%2Cin-process&pivots=programming-language-javascript#concurrency-and-memory-usage

STATUS_STACK_BUFFER_OVERRUN doesn’t mean that there was a stack buffer overrun : https://devblogs.microsoft.com/oldnewthing/20190108-00/?p=100655

相关文章
|
11月前
|
API C++
【Azure 环境】VS Code登录China Azure(Function)报错 An error occurred while signing in: invalid_request - AADSTS65002
An error occurred while signing in: invalid_request - AADSTS65002: Consent between first party application 'c27c220f-ce2f-4904-927d-333864217eeb' and first party resource '797f4846-ba00-4fd7-ba43-dac1f8f63013' must be configured via preauthorization - applications owned and operated by Microsoft mus
508 13
|
存储 安全 数据安全/隐私保护
【Azure Function App】在Function App中使用System Managed Identity访问Storage Account
本文介绍了如何在Azure Function中使用托管身份(Managed Identity)替代AzureWebJobsStorage连接函数应用到存储账户,以提高安全性并减少Access Key的使用。具体步骤包括:1) 启用系统分配的身份;2) 为函数应用授予存储访问权限,添加必要角色(如Storage Blob Data Contributor);3) 配置`AzureWebJobsStorage__blobServiceUri`参数指定Blob Service Uri。完成后删除旧配置,即可通过Managed Identity访问Storage Account。
444 20
|
10月前
|
数据安全/隐私保护
【Azure Function App】PowerShell Function 执行 Get-AzAccessToken 的返回值类型问题:System.String 与 System.Security.SecureString
将PowerShell Function部署到Azure Function App后,Get-AzAccessToken返回值类型在不同环境中有差异。正常为SecureString类型,但部分情况下为System.String类型,导致后续处理出错。解决方法是在profile.ps1中设置环境变量$env:AZUREPS_OUTPUT_PLAINTEXT_AZACCESSTOKEN=false,以禁用明文输出。
247 1
|
11月前
|
JSON 数据格式
【Azure 环境】当一个Azure Function资源创建很久了,是否可以获取到它的创建时间呢?
用户在尝试获取 Azure Function App 的创建时间时发现,资源 JSON 中缺少 `createdTime` 字段,仅能查看到 `lastModifiedTime`。同时,活动日志和 Azure Resource Graph 查询也未能提供创建时间信息。经解答,Azure 并未为所有资源类型记录创建时间,建议在部署时将创建时间作为标签记录。若创建时间在 90 天内,可通过部署日志间接获取。
295 7
|
网络协议 API 网络安全
【Azure Function App】发现部分请求Function App遇见 403.72 报错(请求Body>100KB)
在调用Azure Function的HTTP Trigger时,发送POST请求偶尔出现403错误,且响应为空、Header信息少。经排查发现,当请求Body大于100KB时会触发403.72错误,原因是启用了“Client Certificate mode”为“Optional Interactive User”。解决方法是将该模式设置为“Ignore”。由于TLS重新协商机制限制,大请求体无法正常处理,导致此问题。
338 1
|
存储 数据可视化 开发工具
【Application Insights】Application Insights存储的Function App的日志存在"Operation Link" 为空的情况
在将 Azure Functions 升级到 .NET 8 和 Isolated Worker 模式后,Application Insights 的请求日志中 `operation_Link` 字段为空,导致分布式追踪无法正常关联。解决方法包括:确保引用正确的 SDK 包(如 `Microsoft.Azure.Functions.Worker.ApplicationInsights`),正确配置 Application Insights 服务,移除默认日志过滤规则,并使用最新依赖包以支持分布式追踪。通过这些步骤,可恢复端到端事务视图的可视化效果。
267 11
【Function App】在PowerShell Function中指定特殊的Microsoft.Graph.Users版本
在Azure Function App中运行PowerShell Function时,通过Requirements.psd1文件管理模块版本。若需将“Microsoft.Graph.Users”从最新版2.26.0改回2.23.0以避免冲突,可通过以下步骤解决:1) 在requirements.psd1中明确指定版本为2.23.0 2) 在profile.ps1中添加`Import-Module Microsoft.Graph.Users -RequiredVersion 2.23.0`语句。此方法确保加载特定版本模块
266 18
|
安全 Linux 开发工具
【Azure Function】分享把Function App从.NET 6.0升级到.NET 8.0 Isolated的步骤
本文介绍了将Azure Function App从.NET 6.0升级到.NET 8.0 Isolated的步骤。.NET 6.0作为长期支持版本,生命周期至2024年11月结束。为确保持续支持,建议升级至更新版本。升级步骤包括安装.NET 8 SDK、更新Azure Functions Core Tools、修改项目文件目标框架为net8.0、更新兼容的NuGet包、本地测试以及重新发布到Azure。更多详细信息可参考官方文档。
501 9
|
监控 C#
【Function App】如果一个拥有多个Function App的Plan遇见了High CPU问题? 如何方便定位是哪一个Function App引发的呢?
在Azure Function App测试中,若多个Function App共用同一App Service Plan资源,当出现High CPU问题时,由于Function App公开指标无法直接观测CPU状态,可通过启用Application Insights解决。其Live Metrics功能可过滤并查看每个Function App的CPU使用情况。具体步骤为:将所有Function App连接至同一Application Insights资源,进入Live Metrics页面按Role筛选监控数据。附有三段C#代码示例,分别展示占用CPU、Memory及普通功能的实现方法。
348 36

热门文章

最新文章