[release/6.0] Add SetLastError to GdiPlus methods

[github-actions]

Backport of #59096 to release/6.0

/cc @ericstj

Fixes #58741

Customer Impact

Regression from .NETFramework and .NETCore causing a unexpected ExternalException related to session transitions (sleep/wake, Remote Desktop, etc)

Testing

Manually verified in debugger. Unit tests.

Risk

Very low. Adds back SetLastError to only those PINvokes which require it.

[ghost]

Tagging subscribers to this area: @safern, @tarekgh
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #59096 to release/6.0

/cc @ericstj

Customer Impact

Testing

Risk

Author:	github-actions[bot]
Assignees:	-
Labels:	area-System.Drawing
Milestone:	-

[danmoseley]

Approved. Customer reported. Break introduced since last version. Relatively low risk. Would likely meet servicing bar.

@AaronRobinsonMSFT maybe this discussion already happened, but does this suggest similar breaks may occur in pinvokes in customers code due to the original change?

[danmoseley]

restarting with wasm publish fix.

[danmoseley]

@dotnet/dnceng I reopened the PR to pick up another change and restart validation and lots of legs canceled themselves. I can't see info on Azdo about them. What happened and how do I get them to run?

[danmoseley]

@dotnet/dnceng more mysterious cancellations.

[lukas-lansky]

Interesting! @ChadNedzlek, do you have an idea what might be the problem here?

[MattGal]

@dotnet/dnceng more mysterious cancellations.

Can you link the pipeline that did this? When I click through or look at everything for 59151 in AzDO I see one actively running job.

[AaronRobinsonMSFT]

@AaronRobinsonMSFT maybe this discussion already happened, but does this suggest similar breaks may occur in pinvokes in customers code due to the original change?

As in, if customers were using these P/Invokes directly? I don't think that is possible because they are marked internal but if we have small wrappers around them without calls to Marshal.GetLastWin32Error() then it is definitely possible. In this case though we became too permissive not overly restrictive. By that I mean we made the call and perhaps it errored out in a way we didn't throw an exception where we used to. If users did change their code it was likely to revert to being more restrictive again so they could have added their own Marshal.GetLastWin32Error(). If this was done there is now an inefficiency in user code but nothing else.

I could also be missing what you are asking.

[danmoseley]

@AaronRobinsonMSFT ah, I likely misunderstood the original thread. If indeed this was simply a latent bug in Drawing unrelated to any 6.0 Interop changes, then my question does not apply.

[ericstj]

Yeah, this bug exists in 3.1 and 5.0 as well (and folks have suggested we patch it there as well).