I'm not able to reproduce with Windows 11. Can you upload a sample file that we can test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)

Version: 7.6.0.3 (X86_64) / LibreOffice Community
Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265
CPU threads: 6; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

Please test in safe mode, Menu/Help/Restart in Safe Mode

Created attachment 189435 [details]
Text file containing stickers for jam jars: table with background pictures and text.

The file was stored on a memory card, not the hard disk, so that could possibly have an effect. And Windows keeps downloading and installing updates in the background which often brings my PC to a grinding halt.

I have subsequently replaced LibreOffice 7.6 with 7.5.5. No more problems!

(In reply to m.a.riosv from comment #2)
> Please test in safe mode, Menu/Help/Restart in Safe Mode

Sorry, I can't: I have uninstalled version 7.6 and installed version 7.5.5. No more problems!

(In reply to Odd Nordland from comment #4)
> (In reply to m.a.riosv from comment #2)
> > Please test in safe mode, Menu/Help/Restart in Safe Mode
> 
> Sorry, I can't: I have uninstalled version 7.6 and installed version 7.5.5.
> No more problems!

You can conveniently test with a daily master build - it installs separately and will not mess with your stable one: https://dev-builds.libreoffice.org/daily/master/current.html

(In reply to Buovjaga from comment #5)
> (In reply to Odd Nordland from comment #4)
> > (In reply to m.a.riosv from comment #2)
> > > Please test in safe mode, Menu/Help/Restart in Safe Mode
> > 
> > Sorry, I can't: I have uninstalled version 7.6 and installed version 7.5.5.
> > No more problems!
> 
> You can conveniently test with a daily master build - it installs separately
> and will not mess with your stable one:
> https://dev-builds.libreoffice.org/daily/master/current.html

I let PortableApps update the portable version to 7.6.1. Same problem, both in normal and safe mode: the programs goes unresponsive and doesn't come back. I have to use the task manager to stop it. Both in normal and safe mode.

I then downloaded and installed today's daily master build, version 24.2- Exactly the same problem, both in normal and safe mode.

I'll try on another computer running Windows 10 (fortunately it is not capable of running Windows 11!). I'll post the results when I've done it.

Do you happen to use Windows Speech Recognition? It recently came up that it can cause severe performance problems.

Please test disabling Skia options in Menu/Tools/LibreOffice/View.

(In reply to Buovjaga from comment #7)
> Do you happen to use Windows Speech Recognition? It recently came up that it
> can cause severe performance problems.

No, I don't

(In reply to Odd Nordland from comment #6)
> (In reply to Buovjaga from comment #5)
> > (In reply to Odd Nordland from comment #4)
> > > (In reply to m.a.riosv from comment #2)
> > > > Please test in safe mode, Menu/Help/Restart in Safe Mode
> > > 
> > > Sorry, I can't: I have uninstalled version 7.6 and installed version 7.5.5.
> > > No more problems!
> > 
> > You can conveniently test with a daily master build - it installs separately
> > and will not mess with your stable one:
> > https://dev-builds.libreoffice.org/daily/master/current.html
> 
> I let PortableApps update the portable version to 7.6.1. Same problem, both
> in normal and safe mode: the programs goes unresponsive and doesn't come
> back. I have to use the task manager to stop it. Both in normal and safe
> mode.
> 
> I then downloaded and installed today's daily master build, version 24.2-
> Exactly the same problem, both in normal and safe mode.
> 
> I'll try on another computer running Windows 10 (fortunately it is not
> capable of running Windows 11!). I'll post the results when I've done it.

Nearly the same problem under Windows 10: I can open the file, but then LibreOffice goes unresponsive.

I've noticed through Task Manager that windows sometimes puts a process in "Effectivity mode" which allegedly spares resources. I don't know how or when, but that might be a clue to the source of the problem.

(In reply to Odd Nordland from comment #10)
> Nearly the same problem under Windows 10: I can open the file, but then
> LibreOffice goes unresponsive.
> 
> I've noticed through Task Manager that windows sometimes puts a process in
> "Effectivity mode" which allegedly spares resources. I don't know how or
> when, but that might be a clue to the source of the problem.

I read about Efficiency Mode and it seems it is something you can manually enable for specific processes in Task Manager, so it should not affect LibreOffice.

(In reply to m.a.riosv from comment #8)
> Please test disabling Skia options in Menu/Tools/LibreOffice/View.

Didn't help

(In reply to Buovjaga from comment #11)
> (In reply to Odd Nordland from comment #10)
> > Nearly the same problem under Windows 10: I can open the file, but then
> > LibreOffice goes unresponsive.
> > 
> > I've noticed through Task Manager that windows sometimes puts a process in
> > "Effectivity mode" which allegedly spares resources. I don't know how or
> > when, but that might be a clue to the source of the problem.
> 
> I read about Efficiency Mode and it seems it is something you can manually
> enable for specific processes in Task Manager, so it should not affect
> LibreOffice.

It appears to be generated by Windows when I open a second window in Vivaldi and while I'm not using that window. So it looks like you're right, it doesn't affect LibreOffice.

Hello,

I've reproduce this bug in Windows 10 in versions:

Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-CA (en_CA); UI: en-US
Calc: CL threaded

and

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: cba8c933d1ff2e31ec55544f46d6fff99e8a5ccd
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-CA (en_CA); UI: en-US
Calc: CL threaded

The file opens normally and I was able to do editing without program to crash.

Edition	Windows 10 Pro
Version	22H2
Installed on	‎2021-‎03-‎11
OS build	19045.3448
Experience	Windows Feature Experience Pack 1000.19044.1000.0

Noticing Mike's addition to See Also, wow, looks like we have a Norwegian connection!

Bug 157564: "The error is not reproduced in Windows US version, where the Writer document behaves normally."

(In reply to Buovjaga from comment #15)
> Noticing Mike's addition to See Also, wow, looks like we have a Norwegian
> connection!
> 
> Bug 157564: "The error is not reproduced in Windows US version, where the
> Writer document behaves normally."

Asyou can see from my original bug report, I am also using Norwegian, both for Windows 10 and 11. I'll give the portable version of LibreOffice 7.6 a try on my wife's computer, which is running in German!

*** Bug 157634 has been marked as a duplicate of this bug. ***

*** Bug 157564 has been marked as a duplicate of this bug. ***

Got information from another user who claimed that the version 7.6.2 worked on an "older" edition of Windows.
A closer check revealed that the Windows 10 21H2 - Build 19044.3570 did not have the issues with "not responding" as seen with the latest Windows builds (Windows 10 22H2 - build 19045.3570 and Windows 11 23H2 - build 25967.1010)
All versions are Norwegian Windows versions.

I don't get a stall or a crash with this norskified LibreOffice:

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 7d08767b890e723cd502b1c61d250924f695eb98
CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: default; VCL: win
Locale: nb-NO (nb_NO); UI: nb-NO
Calc: threaded

Nor with this, with locale as nb-NO, but lang as en-US

Version: 7.6.3.0.0+ (X86_64) / LibreOffice Community
Build ID: 35f19e5cb93ce218787904e99c2bedfd40e725cc
CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: default; VCL: win
Locale: nb-NO (nb_NO); UI: en-US
Calc: threaded

Windows 11: Settings - Time & language - Language & region - Administrative language settings - Change system locale

After reboot, Settings - Time & language - Language & region - Regional format

Clarifying to be about locale specifically based on another duplicate

*** Bug 157074 has been marked as a duplicate of this bug. ***

In bug 157074 it was reported that the bibisect version 7.6.3.0.0 does not show the problem. Just to double-check, if the problem was fixed in a later commit, people with the win64-7.6 repo could do

git checkout fb8b2651f68817b9d49c47d61b189e58cf1df9b9

to change to an older build that is closer to 7.6.2, which was reported (in duplicate bugs) to still have the problem. If the problem does not show even in that commit, then there is something different in the release builds vs. bibisect builds.

(In reply to Odd Nordland from comment #16)
> (In reply to Buovjaga from comment #15)
> > Noticing Mike's addition to See Also, wow, looks like we have a Norwegian
> > connection!
> > 
> > Bug 157564: "The error is not reproduced in Windows US version, where the
> > Writer document behaves normally."
> 
> Asyou can see from my original bug report, I am also using Norwegian, both
> for Windows 10 and 11. I'll give the portable version of LibreOffice 7.6 a
> try on my wife's computer, which is running in German!

I have now tried out the portable version of LibreOffice under UK English, German, Danish, Swedish and Norwegian versions of Windows 10. In all cases, the User Interface and Locale for LibreOffice were set to Norwegian.
LibreOffice only stalls in the Norwegian environment.
I notice that I can open a spreadsheet into Calc, but then LibreOffice stalls. Trying to open a text file for Writer stalls immediately.

The LibreOffice version I have done the tests with is
Version: 7.6.0.3 (x86) / LibreOffice Community
Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: nb-NO (nb_NO); UI: nb-NO
Calc: threaded

(In reply to Odd Nordland from comment #24)
> (In reply to Odd Nordland from comment #16)
> > (In reply to Buovjaga from comment #15)
> > > Noticing Mike's addition to See Also, wow, looks like we have a Norwegian
> > > connection!
> > > 
> > > Bug 157564: "The error is not reproduced in Windows US version, where the
> > > Writer document behaves normally."
> > 
> > Asyou can see from my original bug report, I am also using Norwegian, both
> > for Windows 10 and 11. I'll give the portable version of LibreOffice 7.6 a
> > try on my wife's computer, which is running in German!
> 
> I have now tried out the portable version of LibreOffice under UK English,
> German, Danish, Swedish and Norwegian versions of Windows 10. In all cases,
> the User Interface and Locale for LibreOffice were set to Norwegian.
> LibreOffice only stalls in the Norwegian environment.
> I notice that I can open a spreadsheet into Calc, but then LibreOffice
> stalls. Trying to open a text file for Writer stalls immediately.
> 
> The LibreOffice version I have done the tests with is
> Version: 7.6.0.3 (x86) / LibreOffice Community
> Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265
> CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL:
> win
> Locale: nb-NO (nb_NO); UI: nb-NO
> Calc: threaded

N6te that the above mentioned version of Libre Office Portable is what you get when you install using LibreOfficePortable_7.6.2_MultilingualStandard.paf.exe.
I probably have to install the "hard disk" version to get version 7.6.2 or newer ...

(In reply to Odd Nordland from comment #25)
> (In reply to Odd Nordland from comment #24)
> > (In reply to Odd Nordland from comment #16)
> > > (In reply to Buovjaga from comment #15)
> > > > Noticing Mike's addition to See Also, wow, looks like we have a Norwegian
> > > > connection!
> > > > 
> > > > Bug 157564: "The error is not reproduced in Windows US version, where the
> > > > Writer document behaves normally."
> > > 
> > > Asyou can see from my original bug report, I am also using Norwegian, both
> > > for Windows 10 and 11. I'll give the portable version of LibreOffice 7.6 a
> > > try on my wife's computer, which is running in German!
> > 
> > I have now tried out the portable version of LibreOffice under UK English,
> > German, Danish, Swedish and Norwegian versions of Windows 10. In all cases,
> > the User Interface and Locale for LibreOffice were set to Norwegian.
> > LibreOffice only stalls in the Norwegian environment.
> > I notice that I can open a spreadsheet into Calc, but then LibreOffice
> > stalls. Trying to open a text file for Writer stalls immediately.
> > 
> > The LibreOffice version I have done the tests with is
> > Version: 7.6.0.3 (x86) / LibreOffice Community
> > Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265
> > CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL:
> > win
> > Locale: nb-NO (nb_NO); UI: nb-NO
> > Calc: threaded
> 
> N6te that the above mentioned version of Libre Office Portable is what you
> get when you install using
> LibreOfficePortable_7.6.2_MultilingualStandard.paf.exe.
> I probably have to install the "hard disk" version to get version 7.6.2 or
> newer ...

I now installed
Version: 7.6.2.1 (x86) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: nb-NO (nb_NO); UI: nb-NO
Calc: threaded

Calc works, but Writer still stalls when opening a file.

(In reply to Buovjaga from comment #23)
> In bug 157074 it was reported that the bibisect version 7.6.3.0.0 does not
> show the problem. Just to double-check, if the problem was fixed in a later
> commit, people with the win64-7.6 repo could do
> 
> git checkout fb8b2651f68817b9d49c47d61b189e58cf1df9b9
> 
> to change to an older build that is closer to 7.6.2, which was reported (in
> duplicate bugs) to still have the problem. If the problem does not show even
> in that commit, then there is something different in the release builds vs.
> bibisect builds.

Odd and others affected: could you try this? The basic information about bibisecting is in bug 157074 comment 20.

*** Bug 157512 has been marked as a duplicate of this bug. ***

(In reply to Buovjaga from comment #27)
> (In reply to Buovjaga from comment #23)
> > In bug 157074 it was reported that the bibisect version 7.6.3.0.0 does not
> > show the problem. Just to double-check, if the problem was fixed in a later
> > commit, people with the win64-7.6 repo could do
> > 
> > git checkout fb8b2651f68817b9d49c47d61b189e58cf1df9b9
> > 
> > to change to an older build that is closer to 7.6.2, which was reported (in
> > duplicate bugs) to still have the problem. If the problem does not show even
> > in that commit, then there is something different in the release builds vs.
> > bibisect builds.
> 
> Odd and others affected: could you try this? The basic information about
> bibisecting is in bug 157074 comment 20.

If people need help, please email me and we can schedule a screensharing call to work through the process.

Just encountered this issue with a co-workers machine. Is it possible to add a warning (on the download page) for Norwegian Windows users that they should use 7.5-builds until this issue is fixed? It's very hard for non-technical users to figure out that this is a bug, and new users would probably just conclude that LibreOffice doesn't work and use something else instead.

Seems like the issue is related to Norwegian Windows versions, so the warning should possibly be in Norwegian:
Here is a suggestion:
NB: Feil på LibreOffice 7.6 i norsk Windows
Det er observert en feil i LibreOffice 7.6, i forbindelse med norsk utgave av Microsoft Windows. Feilen som oppstår er at programmet blir hengende med "Svarer ikke" når en forsøker å åpne tekstbehandleren Writer. Dette er uavhengig om det åpnes et dokument eller ikke. Det pågår feilsøking rundt denne utfordringen. Feilen er ikke observert i andre språkversjoner av Windows. 
Det anbefales derfor at norske brukere inntil videre i stedet laster ned versjon 7.5.7 i stedet.

Audun, Morten: if you are interested in helping to solve this, my offer in comment 29 still stands.

I have got the exact same problem with LibreOffice version 7.6.0 + 7.6.1 and 7.6.2. Both on Windows 10 and 11.

It easy to reproduce. Just change Regional Format to Norwegian, and Writer will crash upon opening.  Calc will work until you try File>open.

Reset Regional Format back to English, - and LibreOffice 7.6.2 will work again.

Please fix befor version 7.6.3

(In reply to ha from comment #33)
> I have got the exact same problem with LibreOffice version 7.6.0 + 7.6.1 and
> 7.6.2. Both on Windows 10 and 11.
> 
> It easy to reproduce. Just change Regional Format to Norwegian, and Writer
> will crash upon opening.  Calc will work until you try File>open.
> 
> Reset Regional Format back to English, - and LibreOffice 7.6.2 will work
> again.
> 
> Please fix befor version 7.6.3

I have not been able to reproduce it by changing the regional format to Norwegian, so that is why I need your help to bisect it. Please, can you help with what I talk about in comment 29?

Updating summary to Bokmål as no one reported seeing this with Nynorsk. I asked a translator and the problem was not seen under Nynorsk. My own testing was with Bokmål (could not reproduce).

I can confirm that I have no problems using Norwegian Nynorsk under Windows 10.

(In reply to Buovjaga from comment #34)
> (In reply to ha from comment #33)
> > I have got the exact same problem with LibreOffice version 7.6.0 + 7.6.1 and
> > 7.6.2. Both on Windows 10 and 11.
> > 
> > It easy to reproduce. Just change Regional Format to Norwegian, and Writer
> > will crash upon opening.  Calc will work until you try File>open.
> > 
> > Reset Regional Format back to English, - and LibreOffice 7.6.2 will work
> > again.
> > 
> > Please fix befor version 7.6.3
> 
> I have not been able to reproduce it by changing the regional format to
> Norwegian, so that is why I need your help to bisect it. Please, can you
> help with what I talk about in comment 29?

I'm not sure what you mean with "changing the regional format". Goto to Settings 
 | Time and Language | Language. There, select Add a language and download the language package for Norwegian.
There are two varieties of Norwegian, Bokmål and Nynorsk. Download both language packs.
Then set the Windows display language to one of the Norwegian languages and log off and on again. You can do this with any language you have downloaded the language pack for, as often as you like..

(In reply to Odd Nordland from comment #37)
> (In reply to Buovjaga from comment #34)
> I'm not sure what you mean with "changing the regional format". Goto to
> Settings 
>  | Time and Language | Language. There, select Add a language and download
> the language package for Norwegian.
> There are two varieties of Norwegian, Bokmål and Nynorsk. Download both
> language packs.
> Then set the Windows display language to one of the Norwegian languages and
> log off and on again. You can do this with any language you have downloaded
> the language pack for, as often as you like..

I could only change my locale. I can't change the display language. Probably because I am running an unactivated Windows (I use it for bug testing in a virtual machine).

Changing the locale to Nynorsk made the version 7.6.2 work for me! 
That limits the problem to the Norwegian Bokmål version of the Windows Operating system.
Worth mentioning that the language settings in LibreOffice does not affect the behavior.
So it means that this setup works:
Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 12; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: nn-NO (nn_NO); UI: nn-NO
Calc: CL threaded
Similar in Windows 11:
Version: 7.6.2.1 (X86_64) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 4; OS: Windows 10.0 Build 25987; UI render: Skia/Raster; VCL: win
Locale: nn-NO (nn_NO); UI: nn-NO
Calc: threaded
Note: LibreOffice reports Windows 11 23H2 as Windows 10 but with correct build# (Microsoft reports 25987.1000)

Good news: me and Cloph are able to reproduce the problem. Thanks to Cloph, I realised one has to explicitly tick a checkbox to change the display language *when installing the language pack*. So after removing & reinstalling Bokmål I could enjoy a Norwegian Windows and freezing LibreOffice.

Now, the curious thing is that I can't reproduce the freeze in bibisect repositories. Therefore, I need some ideas from developers more familiar with debugging. I could not get a backtrace with WinDbg when killing the stalled process.

Another way to trigger the issue: 
* new Writer document and trying to access Tools|Options (LO not responding)
  + no such problem when trying the same from a new Calc document

→ hints at a issue related to writing aids, since those are initialized when launching Writer (even when there's no text yet)
→ modifying the installation and removing all dictionaries prevents the issue
→ installing Nyorsk dictionary doesn't trigger the problem
→ installing English dictionary does trigger the problem
  → English has lightproof/grammar checking enabled, so maybe other dictionaries with lightproof also can trigger the effect
    + however running python macros (the hello-world and createTable) without dictionaries doesn't cause the problem, so it is not the python initialization itself, but something related to lightproof

Further testing showed that the problem is not the Windows UI language, but Windows Regional Format settings that matter. 
Windows set to English, LibreOffice set to German and regional format set to Norwegian Bokmål breaks.

################
tldr: to test/reproduce it is sufficient that Windows' regional format is set to Norwegian (Bokmål) and that at least the English dictionaries are installed.
################

(In reply to Buovjaga from comment #38)
> (In reply to Odd Nordland from comment #37)
> > (In reply to Buovjaga from comment #34)
> > I'm not sure what you mean with "changing the regional format". Goto to
> > Settings 
> >  | Time and Language | Language. There, select Add a language and download
> > the language package for Norwegian.
> > There are two varieties of Norwegian, Bokmål and Nynorsk. Download both
> > language packs.
> > Then set the Windows display language to one of the Norwegian languages and
> > log off and on again. You can do this with any language you have downloaded
> > the language pack for, as often as you like..
> 
> I could only change my locale. I can't change the display language. Probably
> because I am running an unactivated Windows (I use it for bug testing in a
> virtual machine).

That would explain why you couldn't reproduce the problem and indicates that the problem has something to do with the language pack!

Created attachment 190693 [details]
Windows setting - Regional format

As written earlier: changing regional format (in Windows setting) to Norwegian crashed LibreOfffice.  (Changing language to Nowegian in LibreOffice does not crash LibreOffice.)

(In reply to Odd Nordland from comment #36)
> I can confirm that I have no problems using Norwegian Nynorsk under Windows
> 10.

I just tested LibreOfficePortable version 7.6 under Windows 11 with Nynorsk as language environment. The first attempt stalled (!), but the second try worked.

The version I used was:
Version: 7.6.2.1 (x86) / LibreOffice Community
Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333
CPU threads: 4; OS: Windows 10.0 Build 22631; UI render: default; VCL: win
Locale: no-NO (nn_NO); UI: nn-NO
Calc: threaded

Note that LibreOffice reports Windows as being version 10.0 when the correct version should be Windows 11 Home version 23H2

László: any thoughts on this issue, which is suspected to be about LightProof tripping over localised date & time formats? Microsoft might have updated their definitions and triggered this nasty issue.

Is "LightProof" new in the 7.6 branch? This issue was introduced with 7.6, 7.5.7 does not have this issue.

(In reply to Heraldo from comment #46)
> Is "LightProof" new in the 7.6 branch? This issue was introduced with 7.6,
> 7.5.7 does not have this issue.

No, it is old.

Not fixed in 7.6.3 ....

Hi,
I am using Libreoffice in windows 10 and 11 in Turkish.
I have the same probleme in 3 computers with windows 11: writer is freezing (Libre office 7.6 and later).
I have tried all steps I found on internet with no result (safe mode, disabling Skia etc).
So I have reinstalled previous version 7.5 on these pc.

On my computer running under windows 10: libreoffice (7.6.3) works normally.

I will be please when the bug is corrected.
Thsnks

Looks like the problem is fixed in 7.6.4.1 !!!!!

I found one small issue:
I have an spreadsheet file (.ods) on a memory card which I have edited earlier, so it appeared in the list of previous files. Double clicking on it stalled LibreOffice. Then (after restarting LibreOffice) I tried the open file option. Directly opening the file worked, and after that it also worked when I double clicked the file icon in the list of previous files.

The version data is:
Version: 7.6.4.1 (X86_64) / LibreOffice Community
Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1
CPU threads: 4; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: nb-NO (nb_NO); UI: nb-NO
Calc: threaded

and I have set everything I could set to Norwegian Bokmål. I hope our Turkish friend who had the same kind of problem problem can also report that it is fixed.

(In reply to Odd Nordland from comment #50)
> Looks like the problem is fixed in 7.6.4.1 !!!!!

No, not fixed. I still reproduce with 7.6.4.

(In reply to Buovjaga from comment #51)
> (In reply to Odd Nordland from comment #50)
> > Looks like the problem is fixed in 7.6.4.1 !!!!!
> 
> No, not fixed. I still reproduce with 7.6.4.

I was a bit too optimistic:
I can open files by clicking on the image in the list of previous files. However, this only works the "second" time: if the file had been opened in a previous version of LO, the program would freeze. Closing the program and trying again, the file can be opened. No problems opening a new file.

I can do "elementary" editing:
   - changing, deleting, inserting text
   - changing linewidth and margins directly
   - modifying text attributes (bold, italic, underline etc.)
But: clicking on some of the icons in the menu bar will stall the program. Printing and saving the file works, but print preview or change page style (Alt+5) stall the program. I haven't tried all the possibilities to find out which ones work and which ones don't; it's enough to know that some of them don't ...

After the program has stalled and I restart it, I get the option to recover the previously opened file. That also stalls if I click on yes.

I'm having the identical issue with LibreOffice 7.6.4.1 on Windows 11, Turkish locale.

*** Bug 159557 has been marked as a duplicate of this bug. ***

*** Bug 159604 has been marked as a duplicate of this bug. ***

Not fixed in version 24.2 either (24.2.0.3)

Neither in 24.2.1.

I think I might have the same issue. Also Norwegian OS/Locale 

I have made a WinDBG MiniDump 

Loading Dump File [C:\soffice.bin_240221_135559.dmp]
Comment: '
*** procdump64.exe  soffice.bin -h
*** Hung window detected: 13093c'
User Mini Dump File: Only registers, stack and portions of memory are available

WARNING: Whitespace at end of path element

************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       CACHE*C:\symbols
Deferred                                       SRV*https://dev-downloads.libreoffice.org/symstore/symbols
WARNING: Whitespace at end of path element
Symbol search path is: CACHE*C:\symbols;SRV*https://dev-downloads.libreoffice.org/symstore/symbols;SRV*https://msdl.microsoft.com/download/symbols

Executable search path is: 
Windows 10 Version 19045 MP (4 procs) Free x64
Product: WinNt, suite: SingleUserTS Personal
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
Machine Name:
Debug session time: Wed Feb 21 13:55:59.000 2024 (UTC + 1:00)
System Uptime: not available
Process Uptime: 0 days 0:00:19.000
................................................................
................................................................
................................
Loading unloaded module list
.........
For analysis of this file, run !analyze -v
ntdll!NtWaitForSingleObject+0x14:
00007ffe`0de2d064 c3              ret
0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 27671

    Key  : Analysis.DebugAnalysisManager
    Value: Create

    Key  : Analysis.Elapsed.mSec
    Value: 88788

    Key  : Analysis.Init.CPU.mSec
    Value: 14984

    Key  : Analysis.Init.Elapsed.mSec
    Value: 610778

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 551

    Key  : Timeline.Process.Start.DeltaSec
    Value: 19

    Key  : WER.OS.Branch
    Value: vb_release

    Key  : WER.OS.Timestamp
    Value: 2019-12-06T14:06:00Z

    Key  : WER.OS.Version
    Value: 10.0.19041.1

    Key  : WER.Process.Version
    Value: 73.2.0.0


FILE_IN_CAB:  soffice.bin_240221_135559.dmp

COMMENT:  
*** procdump64.exe  soffice.bin -h
*** Hung window detected: 13093c

NTGLOBALFLAG:  0

PROCESS_BAM_CURRENT_THROTTLED: 0

PROCESS_BAM_PREVIOUS_THROTTLED: 0

APPLICATION_VERIFIER_FLAGS:  0

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 0000000000000000
   ExceptionCode: 80000003 (Break instruction exception)
  ExceptionFlags: 00000000
NumberParameters: 0

FAULTING_THREAD:  00002438

PROCESS_NAME:  icudt73.dll

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION}  Breakpoint  A breakpoint has been reached.

EXCEPTION_CODE_STR:  80000003

STACK_TEXT:  
00000083`3af8ad38 00007ffe`0b0830ce     : 00007ffd`be9477b0 00007ffe`0ae1fc71 00000083`3af8b100 000001fe`61e42940 : ntdll!NtWaitForSingleObject+0x14
00000083`3af8ad40 00007ffd`bd7175fe     : 00000083`3af8af00 00007ffe`0aecbbf8 00000083`00000000 00000000`00000264 : KERNELBASE!WaitForSingleObjectEx+0x8e
00000083`3af8ade0 00007ffd`bd7171c9     : 000001fe`61f5c720 00000083`3af8af10 00000000`00000000 00007ffd`be9477b0 : mergedlo!google_breakpad::ExceptionHandler::WriteMinidumpOnHandlerThread+0x8e
00000083`3af8ae10 00007ffe`0ae22438     : 00000000`000000cb 00000000`00000000 000001fe`6c8e3b20 00007ffe`0ae13a81 : mergedlo!google_breakpad::ExceptionHandler::HandleInvalidParameter+0x1a9
00000083`3af8b730 00007ffe`0ae22379     : 000001fe`75c878a0 00007ffe`0ae13496 00000000`000000cb 000001fe`6c8e3b20 : ucrtbase!_invalid_parameter+0xb4
00000083`3af8b770 00007ffe`0ae508a1     : 000001fe`75c878a0 00000000`00000000 00000000`00000000 00000000`000004e4 : ucrtbase!invalid_parameter_noinfo+0x9
00000083`3af8b7b0 00007ffe`0ae0c3fc     : 00000083`3af8b8f0 00000083`3af8bac8 000001fe`75c878a0 00000000`0000003f : ucrtbase!_mbstowcs_s_l+0x43f91
00000083`3af8b820 00007ffe`0ae0c32f     : 00000000`0000000b 00000000`00000000 00000000`00000000 00000083`3af8b8f0 : ucrtbase!<lambda_2116bde18c9e5f34230805ea4a4660ed>::operator()+0x9c
00000083`3af8b8a0 00007ffe`0ae0c2e7     : 00000083`3af8b9a0 00000000`0000000f 00000000`0000000f 00000083`3af8b920 : ucrtbase!__crt_seh_guarded_call<char *>::operator()<<lambda_e9ce07acdb0b138e546925ae9f1a2c9c>,<lambda_2116bde18c9e5f34230805ea4a4660ed> &,<lambda_5d037afbfc54bf1ca80d3d1ee4062886> >+0x3b
00000083`3af8b8d0 00007ffd`e9a521d5     : 00000000`00000000 000001fe`6c8e3b20 00000000`00000004 000001fe`00000004 : ucrtbase!setlocale+0x47
00000083`3af8b910 00007ffd`e9a44c1e     : 00000000`0000000b 00000000`00000000 00000083`3af8ba70 00000000`0000000f : msvcp140!std::_Locinfo::_Locinfo_dtor+0x15
00000083`3af8b940 00007ffd`bd6c6d16     : 00000083`3af8ba00 00000000`0000000f 00000083`3af8ba00 00000000`00000000 : msvcp140!std::_Locinfo::~_Locinfo+0xe
00000083`3af8b970 00007ffd`bd6c7eca     : 00009f1e`ccd09ef1 00007ffd`bd6c7bd2 00000083`3af8bae8 00000000`00000010 : mergedlo!std::locale::locale+0x136
00000083`3af8ba50 00007ffd`bd6c7b02     : 000001fe`75859220 00000083`3af8bb09 00000000`0000000f 00000000`00000000 : mergedlo!boost::locale::impl_std::std_localization_backend::loadable+0x3a
00000083`3af8baa0 00007ffd`bd6c7f67     : 00000000`00000039 00000000`00000010 000001fe`75859140 00000000`00000001 : mergedlo!boost::locale::impl_std::std_localization_backend::prepare_data+0x372
00000083`3af8bb70 00007ffd`bd6c36d3     : 000001fe`75386be0 00000083`3af8bf30 00000083`3af8bee8 00007ffe`02fe0000 : mergedlo!boost::locale::impl_std::std_localization_backend::install+0x47
00000083`3af8bd50 00007ffd`bd6be90d     : 000001fe`75c69420 000001fe`61ed34a0 00000083`3af8be39 000001fe`75c69420 : mergedlo!boost::locale::localization_backend_manager::impl::actual_backend::install+0x73
00000083`3af8bd90 00007ffd`bca15e25     : 00000083`3af8bee8 00000083`3af8bf30 000001fe`61ed34a0 00000083`3af8bf50 : mergedlo!boost::locale::generator::generate+0x17d
00000083`3af8bea0 00007ffd`bcb13a08     : 00000083`3af8c118 00000083`3af8c0c0 00000083`3af8c0c0 000001fe`755f0930 : mergedlo!Translate::Create+0x515
00000083`3af8bfc0 00007ffd`bcb06a04     : 000001fe`755f0948 00000083`3af8e7c8 00000000`0000001b 00000083`3af8e5e8 : mergedlo!VclBuilder::handleChild+0x448
00000083`3af8d1d0 00007ffd`bd00769a     : 000001fe`75b8b018 00000083`3af8e5e8 000001fe`75829c40 00007ffe`0ae0fde6 : mergedlo!VclBuilder::VclBuilder+0x3b4
00000083`3af8e4d0 00007ffd`bd00b958     : 000001fe`6c136870 000001fe`6722df10 000001fe`75829c40 000001fe`00000000 : mergedlo!SalInstanceBuilder::SalInstanceBuilder+0xaa
00000083`3af8e550 00007ffd`bcb053c3     : 00007ffd`d34b4fed 00000000`00000000 000001fe`75b8b018 000001fe`61e40000 : mergedlo!SalInstance::CreateBuilder+0x98
00000083`3af8e5b0 00007ffd`bd059900     : 000001fe`75829d18 00000000`00000000 000001fe`75b8b000 00000083`3af8e690 : mergedlo!Application::CreateBuilder+0x1e3
00000083`3af8e610 00007ffd`cf919039     : 000001fe`75b8b000 000001fe`75829d18 00000083`3af8e760 00000000`00000000 : mergedlo!weld::GenericDialogController::GenericDialogController+0x50
00000083`3af8e660 00007ffd`cfa60d30     : 000001fe`75b8b000 000001fe`75d771e0 00000000`00000000 000001fe`7584c8b0 : cuilo!TipOfTheDayDialog::TipOfTheDayDialog+0x99
00000083`3af8e7b0 00007ffd`bb89e3e8     : 00000000`00000000 000001fe`75b8aff0 00000000`00000000 000001fe`7596da00 : cuilo!AbstractDialogFactory_Impl::CreateTipOfTheDayDialog+0x60
00000083`3af8e810 00007ffd`bb923849     : 000001fe`6be3abf0 000001fe`6be3abf8 00000000`00000000 00000000`0001c000 : mergedlo!SfxApplication::MiscExec_Impl+0x1188
00000083`3af8eee0 00007ffd`bb926115     : 00000000`00000000 00000000`00000000 00000000`00000001 00000083`3af8f058 : mergedlo!SfxDispatcher::Call_Impl+0x279
00000083`3af8efa0 00007ffd`bbbd64bd     : 000001fe`75308970 000001fe`663f151f 000001fe`74fa0000 000001fe`74faf410 : mergedlo!SfxDispatcher::ExecuteList+0x5f5
00000083`3af8f0c0 00007ffd`bbdaa569     : 00000000`00000000 00000000`00000004 000001fe`6c8de980 00000000`00000000 : mergedlo!SfxViewFrame::Notify+0x39d
00000083`3af8f570 00007ffd`bb87f05b     : 000001fe`6c493f20 00000000`00000001 00000000`00000018 00000000`00000000 : mergedlo!SfxBroadcaster::Broadcast+0x59
00000083`3af8f5a0 00007ffd`bd02fa8d     : 00000000`00000002 00000000`00000001 00000000`00000002 00000000`00000018 : mergedlo!`anonymous namespace'::SfxEventAsyncer_Impl::LinkStubIdleHdl+0x7b
00000083`3af8f5e0 00007ffd`d34082e1     : 000001fe`61f5e4e0 000001fe`678023d0 000001fe`678023d0 000001fe`6be37f60 : mergedlo!Scheduler::CallbackTaskScheduling+0x40d
00000083`3af8f6b0 00007ffd`d34019af     : 00000000`00000000 00000000`00000000 000001fe`678023d0 000001fe`6be37f60 : vclplug_winlo!WinSalTimer::ImplHandleElapsedTimer+0xc1
00000083`3af8f6e0 00007ffd`d3401af1     : 00000000`00000001 00000000`00000001 00000000`00000000 00007ffd`d3401a7a : vclplug_winlo!ImplSalYield+0xff
00000083`3af8f760 00007ffd`bd04487a     : 00007ffd`00000001 00000000`00000001 00000083`3af8f8f0 00000000`00000000 : vclplug_winlo!WinSalInstance::DoYield+0x91
00000083`3af8f790 00007ffd`bd0447e5     : 000001fe`61ee56f0 00000000`00008000 00007ffd`bf929a50 00000083`3af8fa60 : mergedlo!ImplYield+0x5a
00000083`3af8f7c0 00007ffd`bbc0a14d     : 00007ffd`00000000 00007ffd`e64c2048 00007ffd`bf822200 000001fe`6c301de0 : mergedlo!Application::Execute+0x75
00000083`3af8f7f0 00007ffd`bd054222     : 000001fe`671318d0 00007ffd`bf90c180 00000000`00000000 00007ffd`bf929a50 : mergedlo!desktop::Desktop::Main+0x10fd
00000083`3af8f9d0 00007ffd`bbc2ce4d     : 00000083`00000000 000001fe`61f4ea70 00007ffd`bf90c180 000001fe`61eccad0 : mergedlo!ImplSVMain+0x62
00000083`3af8fa10 00007ff6`c284101b     : 000001fe`61f4ed90 000001fe`61eccad0 00000083`3af8fae0 000001fe`61eccad0 : mergedlo!soffice_main+0x26d
00000083`3af8fb20 00007ff6`c28412d4     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : soffice!main+0x1b
00000083`3af8fb50 00007ffe`0c437344     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : soffice!__scrt_common_main_seh+0x10c
00000083`3af8fb90 00007ffe`0dde26b1     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0x14
00000083`3af8fbc0 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21


STACK_COMMAND:  ~0s; .ecxr ; kb

FAULTING_SOURCE_LINE:  C:\cygwin64\home\buildslave\r\workdir\UnpackedTarball\breakpad\src\client\windows\handler\exception_handler.cc

FAULTING_SOURCE_FILE:  C:\cygwin64\home\buildslave\r\workdir\UnpackedTarball\breakpad\src\client\windows\handler\exception_handler.cc

FAULTING_SOURCE_LINE_NUMBER:  726

SYMBOL_NAME:  mergedlo!google_breakpad::ExceptionHandler::WriteMinidumpOnHandlerThread+8e

MODULE_NAME: mergedlo

IMAGE_NAME:  mergedlo.dll

FAILURE_BUCKET_ID:  BREAKPOINT_80000003_mergedlo.dll!google_breakpad::ExceptionHandler::WriteMinidumpOnHandlerThread

OS_VERSION:  10.0.19041.1

BUILDLAB_STR:  vb_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

IMAGE_VERSION:  7.6.4.1

FAILURE_ID_HASH:  {0e303778-f9ad-7157-1b84-acb7b77165e3}

Followup:     MachineOwner
---------

I have the same problem on two different PCs, one with Win 10 and one with Win 11. Both with Norwegian set as language.

It would probably be helpful if more people could produce a minudump. 

See https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg#Producing_a_mini_dump 

Instructions to install Windbg is in the same page. 
I was not able to do a debugging run as Windbg would not attach to soffice.exe for whatever reason.

(In reply to SSamiK from comment #60)
> It would probably be helpful if more people could produce a minudump. 
> 
> See
> https://wiki.documentfoundation.org/
> How_to_get_a_backtrace_with_WinDbg#Producing_a_mini_dump 
> 
> Instructions to install Windbg is in the same page. 
> I was not able to do a debugging run as Windbg would not attach to
> soffice.exe for whatever reason.

Not sure, if that's a useful way to spend time. The problem source is know, it is in LightProof, so its Python code should be examined and the actual problem discovered. I'm not sure how to do it except removing bits until things work...

And it is confirmed it is in LightProof the error resides? 
I have tried renamed LightProof.py and associated folder and the same error still occurs.

(In reply to SSamiK from comment #62)
> And it is confirmed it is in LightProof the error resides? 
> I have tried renamed LightProof.py and associated folder and the same error
> still occurs.

See comment 41, it is confirmed.

Can you confirm that you renamed all of these:

C:\Program Files\LibreOffice\share\extensions\dict-en\Lightproof.py
C:\Program Files\LibreOffice\share\extensions\dict-en\pythonpath

And you are not seeing LightProof in Tools - Options - Languages and Locales - Writing Aids?

Confirmed. 


C:\Program Files\LibreOffice\share\extensions\dict-en\Lightproof.old
C:\Program Files\LibreOffice\share\extensions\dict-en\pythonpath-old

And you are not seeing LightProof in Tools - Options - Languages and Locales - Writing Aids?
 
Not seeing LightProof in Writing Aids.

(In reply to SSamiK from comment #64)
> Confirmed. 
> 
> 
> C:\Program Files\LibreOffice\share\extensions\dict-en\Lightproof.old
> C:\Program Files\LibreOffice\share\extensions\dict-en\pythonpath-old
> 
> And you are not seeing LightProof in Tools - Options - Languages and Locales
> - Writing Aids?
>  
> Not seeing LightProof in Writing Aids.

Ok, I tested it now and the only thing you need to rename is Lightproof.components. If I do it, I can use the file dialog.

Well look at that. Can confirm!  
I did the same thing and it works.

I  even gave the two other their names back and it still works with just renaming Lightproof.components

As expected: regression after commit ed259e5efe432386b54c553cbc644b3b64976852.

The hang / crash appears in the boost::locale::generator::operator() (https://opengrok.libreoffice.org/xref/core/unotools/source/i18n/resmgr.cxx?r=dcea29c2#205), when trying to instantiate "en-US.UTF8" locale, which is actually not defined on Windows. Interesting is the text before that point, explaining some problems with "invalid locale", and installing hooks to intercept the problems.

Despite the precautions, the problem results in a crash in CRT, which gets intercepted by our crashreport service. And it also tries to use the CRT, which is in a hung state, so everything is locked to death.

https://gerrit.libreoffice.org/c/core/+/164068

FTR: for me, it was important that non-Unicode language is also set to the Norwegian (Bokmål) before the problem could be reproduced.

Let's say it's practically fixed.

Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/072a25e1ef4815bbef4f18f59f025862a0d8e876

tdf#157135 workaround: restore and update windows-no-utf8-locales.patch.0

It will be available in 24.8.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

FTR: submitted a bug to Microsoft:
https://developercommunity.visualstudio.com/t/setlocale-may-crash-CRT-in-some-cases/10603395

(In reply to Mike Kaganski from comment #67)
> when trying to instantiate "en-US.UTF8" locale, which is actually not defined
> on Windows.

For completeness / correctness: the bug appeared on Windows 11 *exactly because* Windows 11 now started to support these UTF-8 locales. And not all code in MS CRT is prepared to handle that. That is mentioned in the bug report in comment 71.

Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-24-2":

https://git.libreoffice.org/core/commit/97d37a63a9adaff2256944189b9454373d192dcb

tdf#157135 workaround: restore and update windows-no-utf8-locales.patch.0

It will be available in 24.2.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-7-6":

https://git.libreoffice.org/core/commit/b6f2c7a64dd3c80161db630b9b28ad1b228a1c9f

tdf#157135 workaround: restore and update windows-no-utf8-locales.patch.0

It will be available in 7.6.6.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Confirmed working in daily build 7.6.6 (2024-03-02_10.13.00/)
Still awaiting new daily build of 24.2.2

Confirmed working with latest daily of 24.2.2 (2024-03-04_08.14.56)

Could someone give me a summary of what this is? I have a similar issue that has been transferred to this thread.

I've noticed a bug in the Norewegian version of LibreOffice 7.6.2.5 and 24.2. 

I have two laptops with Windows 11 (x86_64), updated of course, and after I updated LibreOffice to 7.6.2.5 the other day I can’t save files. The save process freezes telling me Not Responding. This occurs in all LibreOffice programs, both Writer, Calc and the others.

On the laptops with this setup, LibreOffice doesn't work;
Version: 7.6.5.2 (X86_64) / LibreOffice Community
Build ID: 38d5f62f85355c192ef5f1dd47c5c0c0c6d6598b
CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: nb-NO (nb_NO); UI: nb-NO
Calc: threaded

I have tried to:
- Reinstall Libreoffice 7.6.2.5
- Start in safe mode and reset my profile
- Reinstall Windows 11
- Run Ccleaner
- Installed LibreOffice 24.2 but the same thing happened there
- Change to use LibreOffice-dialogs
- Reverted from 24.2 to 7.6.2.5 with no luck, still freeze.
- The same hang/freeze happens regardless of whether I choose the save button or goes to the menu and select Save, Save-as and ctrl-s.
- Tried tp adde LibreOffice (soffice.bin) to the Allowed list in Windows Defender
- I've tried to restart my laptops several times

None of the points above allow me to save the files.

Libreoffice stalls in the Norwegian environment when saving under 7.6.2.5. When going back to 7.5.9.2 (still Norwegian version) I'm able to save documents.

(In reply to Bjørn Ryan Johansen from comment #78)
> Could someone give me a summary of what this is? I have a similar issue that
> has been transferred to this thread.
> 
> I've noticed a bug in the Norewegian version of LibreOffice 7.6.2.5 and
> 24.2. 

Update to 24.2.2 when it arrives

https://wiki.documentfoundation.org/ReleasePlan/24.2#24.2.2_release

or use a pre-release: https://www.libreoffice.org/download/pre-releases/

*** Bug 160128 has been marked as a duplicate of this bug. ***

Ive tried to install the latest version 24.2.1, but I keep getting "Internal error 2503" followed by "Internal error 2502".

I had reset my PC to bokmål, so I tried uninstalling version 7.6.4.1 before installing the new version. The uninstall process also gave me the above error messages!

Then I set my PC back to nynorsk and tried to install again. Same result. Then I tried uninstalling version 7.6.4.1 first. Still the same result.

The unit specification (in nynorsk) is:
Enhetsnavn	DESKTOP-74TODF7
Prosessor	Intel(R) Pentium(R) Silver N5000 CPU @ 1.10GHz   1.10 GHz
Installert RAM	4,00 GB (3,83 GB kan brukast)
Enhets-ID	E1BF9A11-EC21-4D94-B588-0146696F2C69
Produkt-ID	00356-02228-74451-AAOEM
Systemtype	64-bitars operativsystem, x64-basert prosessor
Penn og berøring	Ingen penne- og berøringsinndata er tilgjengelige for denne skjermen

and the Windows specification is (also in nynorsk):
Versjon	Windows 11 Home
Versjon	23H2
Installert den	‎29.‎01.‎2023
Operativsystembygg	22631.3235
Opplevelse	Windows Feature Experience Pack 1000.22687.1000.0

So I don't consider the bug to be fixed yet.

(In reply to Odd Nordland from comment #81)
> Ive tried to install the latest version 24.2.1, but I keep getting "Internal
> error 2503" followed by "Internal error 2502".

Why are you not testing with version 24.2.2, which actually has the fix? You can get it from https://www.libreoffice.org/download/pre-releases/

Because 24.2.1 is the version I found on the LibreOffice download page https://www.libreoffice.org/download/download-libreoffice/

(In reply to Odd Nordland from comment #83)

Please only reopen if you:

1. Have read and understood, in which version the fix is;
2. And found and downloaded the version that has the fix;
3. And actually tested that version;
4. And that version exhibited the *same* problem as expected to be fixed.

Failing any of the points above, e.g. when you downloaded a version that is known to be older than the one that has a fix, or was unable to install it to really test (like having "Internal error 2503/Internal error 2502" Windows Installer messages, indicating  insufficient rights), is *not* a reason to reopen this.

Thank you.

(In reply to Odd Nordland from comment #83)
> Because 24.2.1 is the version I found on the LibreOffice download page
> https://www.libreoffice.org/download/download-libreoffice/

Note also, that that download page *does* contain a link to 24.2.2, as a *prerelease* version, at the very bottom of the page.

*** Bug 160006 has been marked as a duplicate of this bug. ***

*** Bug 160216 has been marked as a duplicate of this bug. ***

*** Bug 157195 has been marked as a duplicate of this bug. ***

*** Bug 160387 has been marked as a duplicate of this bug. ***