osu!lazer won't run after 2019.1011.0 update

[Sinamer]

Describe the crash: It returns system error upon launch

Screenshots or videos showing encountered issue:

osu!lazer version: 2019.1011.0

Logs: Not sure if it gets logged, here's the only one that was updated
runtime.log

Computer Specifications:
Windows 10 Pro build 16299, 64-bit
CPU: Intel(R) Celeron(R) CPU B800
GPU: Intel(R) HD Graphics
2gb RAM

[bdach]

The OpenGL initialization header is concerning:

2019-10-13 02:21:43: GL Initialized
2019-10-13 02:21:43: GL Version:                 1.1.0
2019-10-13 02:21:43: GL Renderer:                GDI Generic
2019-10-13 02:21:43: GL Shader Language version:
2019-10-13 02:21:43: GL Vendor:                  Microsoft Corporation
2019-10-13 02:21:43: GL Extensions:              GL_WIN_swap_hint GL_EXT_bgra GL_EXT_paletted_texture

I'm pretty sure a generic GDI renderer should not be used by the game with your GPU. Are you sure Windows hasn't installed generic drivers for your card? Do you mind trying to update them?

Although it is weird that this would surface after upgrading - does downgrading lazer again help? If it does, mind attaching log output from the previous version?

[Sinamer]

Downgrading to 2019.930.0 again helps, here are the logs:
performance.log
runtime.log
updater.log
network.log

[bdach]

Looks good on the old version, weirdly enough the reported system version changes too...?

2019-10-13 02:58:17: GL Initialized
2019-10-13 02:58:17: GL Version:                 3.1.0 - Build 9.17.10.4459
2019-10-13 02:58:17: GL Renderer:                Intel(R) HD Graphics
2019-10-13 02:58:17: GL Shader Language version: 1.40 - Intel Build 9.17.10.4459
2019-10-13 02:58:17: GL Vendor:                  Intel

Do you mind checking the Windows Event Viewer for any potentially related errors around the time of launch of the new version? Sorry for the hassle, but this issue seems rare (as it hasn't been reported yet) and particularly bizarre.

[Sinamer]

There is an error, it says:

Application: osu!.exe
CoreCLR Version: 4.700.19.46205
.NET Core Version:
Description: The process was terminated due to an internal error in the .NET Runtime at IP 00007FFDD3E64523 (00007FFDD3CB0000) with exit code c0000005.

Tell me if I understood it wrong

[bdach]

Thanks for looking - unfortunately this is virtually the same error as the dialog shows, and is similarly unhelpfully non-specific, at least to me - all it says is that there was an access violation (0xc0000005) at the given instruction pointer.

[enoslayd]

i also suffered from this issue now when updated to 1011.0 but it doesnt have any dialog box
performance.log
runtime.log
updater.log
database.log
network.log

[bdach]

@enoslayd Please do not post double comments. Do you mind giving your PC specifications (in particular the GPU make and model)?

[enoslayd]

sorry. i didnt know what happenned though

[enoslayd]

intel core i3 540m 3.07 ghz
no gpu (intel hd graphics only)
2GB ram
256GB SSD

i will try this update on my laptop later

[peppy]

This has got to be related to the net core 3.0 update, but very weird that GL is detecting different underlying hardware..

[smoogipoo]

As for the version being different, that's expected with .NET Core 3.0, see: https://github.com/dotnet/coreclr/issues/22844 / https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0/ . This may require an osuTK fix.

[enoslayd]

in my laptop, there is this window "osu framework running "osu"" and it still crashing

Specs:
Intel pentium P6200 2.13 GHz dual core
4 GB ram
No gpu (intel hd graphics only)
250 GB SSD

runtime.log

[Joppe27]

I have the same issue, osu! doesn't launch since 2019.1011.0 update. System specs so you guys can get some more info:

• Processor: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz
• GPU: Intel HD Graphics (Core i5); Intel64 Family 6 Model 37 Stepping 5
• RAM: 4GB
• 250 GB SSD
  Hope this helps you out in finding out what causes this error.
  Logs

[MeguMario]

For those who really want to try out 2019.1011, 2019.1021.0 and 2019.1029.0 on affected machines, there is a way that will involve system files replacing, so do this if you really want to try it

Credit: libretro/RetroArch#4580 (comment)

Files
Intel_OpenGL_Win10_9.17.10.4459_Fix_x64.zip

2019.1029.0

2019.1021.0

Again, not recommended to do so, it's best to wait for a fix

[bdach]

@MeguMario Thanks for linking that actually, it's very helpful! Looking through the threads I stumbled upon this comment in the LWJGL repository, which seems to indicate this is Intel device driver breakage - it seems to die if the major Windows version is not 5 or 6.

I had a look at the Windows binaries pre- and post-2019.930.0 inside a hex editor, and found the manifest before and after the .NET Core 3.0 bump.

• 2019.930.0 has no <compatibility> element in the manifest.
• Newer releases have a <compatibility> element, and declare compatibility with Windows 10.

Since I can't reproduce I can't confirm, but if we found a way to patch that element out of the releases, then this could maybe go away, if what the comment claims is correct (ie. the manifest is used to get the version)? Don't get me wrong, it's a real hack for some prime Intel breakage.

It could also be not enough, and the root cause could be .NET Core changing the returned Windows version altogether, in which case short of reversing the actual drivers and binary patching the check out of it (I... don't see that happening) we might be screwed.

In summary, Windows version tests are evil and don't ever do them.

[MeguMario]

@MeguMario Thanks for linking that actually, it's very helpful! Looking through the threads I stumbled upon this comment in the LWJGL repository, which seems to indicate this is Intel device driver breakage - it seems to die if the major Windows version is not 5 or 6.

I had a look at the Windows binaries pre- and post-2019.930.0 inside a hex editor, and found the manifest before and after the .NET Core 3.0 bump.

• 2019.930.0 has no <compatibility> element in the manifest.
• Newer releases have a <compatibility> element, and declare compatibility with Windows 10.

Since I can't reproduce I can't confirm, but if we found a way to binary patch that element out of the releases, then this could maybe go away, if what the comment claims is correct (ie. the manifest is used to get the version)? Don't get me wrong, it's a real hack for some prime Intel breakage.

It could also be not enough, and the root cause could be .NET Core changing the returned Windows version altogether, in which case short of reversing the actual drivers and binary patching the check out of it (I... don't see that happening) we might be screwed.

In summary, Windows version tests are evil and don't ever do them.

I should also mention that some driver even broke on Windows 8/8.1 (mostly GMA x4500 and lower)

[huoyaoyuan]

Have you tried to run it in compatibility mode?

Windows will report your selected OS version in compatibility mode.

[Sinamer]

I still get a crash with Windows 7 compatibility mode
No logs, two errors in Event Viewer:
https://drive.google.com/open?id=1HFe6KuqKDsLrLxElm80EAjg92UGSOOH0

[MeguMario]

ave you trie

sadly it is seem to be the driver, compatbility mode won't get you anywhere

[pal1000]

Here is a video tutorial that describe all possible fixes to this problem with full demonstration of compatibility shim method which I believe is best of all

[bdach]

@pal1000 Thanks for the video and for confirming that removing the manifest entries does indeed fix it! It's a band-aid workaround, but in my opinion it's the best way for us to provide out-of-the-box compatibility with older Intel cards, unless it turns out the compatibility entries help with something else. I'm pretty sure we should be able to modify the manifest at source-level, which would end up propagating to the released binaries.

(The irony of added compatibility entries making the game less compatible with hardware due to broken Intel drivers that they won't fix is not lost on me.)

[bdach]

Could anyone who has this problem test out #7088 and confirm for sure that it fixes it? Would be much appreciated, as I don't have the appropriate hardware on hand.

[doughn0]

I can confirm that it works for me, I have an Intel HD 3000.

Old log:
runtime.log

Log from that pull:
runtime.log

[bdach]

@doughn0 Great to hear, thanks so much for checking!