Process finished with exit code -1073740940 (0xC0000374)

[mkolew]

For which library do you need help?

native-federation

Question

In the past 2 weeks we were migrating our applications from module federation to native federation. Everything went smooth. After some time some colleagues started complaining about an issue when they run ng serve.

Process finished with exit code -1073740940 (0xC0000374)

I am using mac and I never experienced this issue. Simple google search says it's a "Windows error indicating a heap corruption issue". The issue happens 4 out of 5 times when running ng serve. When they switch to a branch with a module federation, the issue doesn't happen.

Any idea what might cause this issue and how it's related to the native federation ?

[M4R1KU]

We observe the same problem, also after switching from module to native federation. Only on Windows, Linux works fine.

node @ 22.21.0
@angular-architects/native-federation @ 20.1.6
@angular/* @ 20.3.2

[manfredsteyer]

Thanks for pointing this out. We need to fix this asap.

[manfredsteyer]

I just tried to reproduce this, however, I was not able. Can you please provide a minimal reproduction of the problem?

[M4R1KU]

I am not yet able to provide a reproduction. I tried initializing a new project (as shown in the instructions of nf) and the first time I started it failed with the reason indicated above. However, since then it never failed again, so there must be some other confounding factor.

It is almost definitely only a problem with ng serve. I never observed an error when executing ng build.
For my work project, which I can obviously not share, it also happens around 4 out of 5 times.

I will try to reproduce it in a shareable project, but I only have limited time, so if anyone else has a shareable project, that would be great.

[M4R1KU]

@manfredsteyer It is not perfect, but at least I get the error ~2 out of 5 times when running ng serve.

https://github.com/M4R1KU/nf-build-failure-reproduction

Basically what I did, is initialize the project and replace shareAll with share and then it occurred again, maybe this has something to do with it.

Can you just try that on your machine and see whether it fails as well? I always cleared the caches in node_modules/.cache after every run, because when it worked once, it worked on the subsequent runs also.

Hope this helps 🥴

[wamasimba]

I have been debugging into native-federation builder.ts, and see it crashes on my system in the serveWithVite between line and the active loop that starts on line 202 ; narrowing in on the culpritt...

It seems it crashes on the line

const { createServer, normalizePath } = await import('vite');

[manfredsteyer]

Thanks for this info. I will look into asap.

In between, can you please also tell me your node version?

[wamasimba]

I'm using node --version: v22.15.1
I'm not sure about the other colleagues who're now experiencing this, but I know we've got a migrating to node 24 planned soon...

[wamasimba]

Ì just discovered a notable difference between the code in the repo and my locally installed package; in @angular/* 20.3.7 that actual line was changed less than 2 days ago.. Now trying what that changes for this situation...

[wamasimba]

The particular change was for Angular 21, and this change was not in the update to Angular 20.3.7. So, it fails just the same.
I also hacked my Angular 20.3.7 package to use the more modern way to load vite, but to no avail.

[manfredsteyer]

Big thanks. Hm, it's somehow strange. I don't manage to reproduce it on my Windows 11 Pro.

I have a slightly different node version that is LTS now:
v22.21.0

Perhaps it's worth trying with that one.

[wamasimba]

So, my findings are:
This does not seem to depend on node version; I used 22.15.0, 22.21.0, and even 24.10.0; they all fail in the same way. I set node's memory limits sufficiently high, as to avoid that barrier.
I found a makeshift solution (aka hack) by replacing the line that loads vite (in node_modules\@angular\build\src\builders\dev-server\vite-server.js) from

const { createServer, normalizePath } = await (0, load_esm_1.loadEsmModule)('vite');

into

const { createServer, normalizePath } = await import('vite');

WIth this, the process runs as it should, but I don't think is an acceptable solution!

The loadEsmModule seems innocent enough, the code boils down to that same import. Somehow, it seems it can't load the ESM module properly at this point, and just bails out completely. My gut tells me there should be something in the state/memory of the process that causes this, but for now I don't have a clue as to what that might be...

NB: I tried try .. catch around it to see if I could find more info, but it crashes hard.

[berkon]

I'm facing the same issue. Funny! I tried exactly all the same things you guys did already. :-) Then my description below might just be a summarization of your findings. But I think I also found some additional things:

I'm seeing the issue in approx. 50% - 75% of the cases when I run ng serve, I'm only seeing "Building federation artefacts and then I'm back at the prompt. I'm getting the same process exit code like you 0xC0000374 which indeed is a Windows heap corruption error. With Angular 20.3.3 everything worked fine. It started breaking with 20.3.4. But I think this is probably just a race condition which simply does not show up in 20.3.3. I couldn't find any related changes in the commits for Angular 20.3.4. By the way I also tried the latest Node 25 with the same result. As some of you stated already, the issue is triggered by this line:

const { createServer, normalizePath } = await (0, load_esm_1.loadEsmModule)('vite')

in: .\node_modules\@angular\build\src\builders\dev-server\vite-server.js

Line 141. I saw that in this quite recent commit for Angular 21: angular/angular-cli@b356bb1 the line was changed to:

const { createServer, normalizePath } = import('vite');

That was what I also already tried on my own, but without success. It looks like this import() crashes Node. I'm preparing a small reproduction. While stripping down my current code I can confirm that shareAll() causes the problem. But I can also reproduce it when removing shareAll() and just putting:

  shared: {
    '@angular/common': {
      singleton: true,
      strictVersion: true,
      requiredVersion: 'auto'
    }
  }

In my case I'm loading a small module into my router:

export const routes: Routes = [{path: '', loadChildren: () => DemoModule}];

and I found out that as soon as I add CommonModule to @NgModule like this, it starts failing:

@NgModule({
  imports: [CommonModule]
})

[berkon]

Here you can find my reproduction: https://github.com/berkon/ng-serve-crash-reproduction

Just do: npm install and npm start

As said its not 100% and maybe it behaves differently on different machines due to the nature of the issue.