Skip to content

[release/7.0] Fix edit and continue in VS with hardware exceptions - #76427

Merged
carlossanlop merged 1 commit into
release/7.0from
backport/pr-76401-to-release/7.0
Sep 30, 2022
Merged

[release/7.0] Fix edit and continue in VS with hardware exceptions#76427
carlossanlop merged 1 commit into
release/7.0from
backport/pr-76401-to-release/7.0

Conversation

@github-actions

@github-actionsgithub-actionsBot commented Sep 30, 2022•
edited by jkotas
Loading

Copy link
Copy Markdown
Contributor

Backport of #76401 to release/7.0

/cc @janvorli

Customer Impact

Without this fix, using the "unwind to this frame" functionality in Visual Studio after a hardware exception like null reference causes the debugged process to crash.

Testing

Local testing with Visual Studio, monitoring the state of the target process using non-invasively attached WinDbg at the same time and comparing the behavior with .NET 6.

Risk

Very low, it touches only the hardware exception handling path and influences only the debugger behavior.

@janvorli
Fix edit and continue in VS with hardware exceptions
0fb9b84
There is a subtle bug in hardware exception handling in the runtime
that causes the debugged process to crash when a user tries to use the
"unwind to this frame" on the frame where the exception happened.
This issue was introduced by the recent changes that modified hardware
exception handling.
The problem turned out to be in how we update the exception and context
records in the HandleManagedFaultFilter when we re-raise the exception
using RaiseException from the VEH. Updating the context is both not
necessary and wrong. All we need to update is the `ExceptionAddress` in
the `EXCEPTION_RECORD`, since the RaiseException puts the address of
itself there and we need the address of the original access violation to
be there.
The context should stay untouched as we are unwinding from the
RaiseException.
The context copying was originally made to mimick the code in the
`NakedThrowHelper` used before the exception handling change. That one
needed the context update, as it was used to fix unwinding over the
NakedThrowHelper that was a hijack helper. In the current state, nothing
like that is needed.
With this fix, the VS debugger works as expected.
@ghostghost added the area-ExceptionHandling-coreclr only use for closed issues label Sep 30, 2022
@janvorlijanvorli self-assigned this Sep 30, 2022
@janvorlijanvorli added this to the 7.0.0 milestone Sep 30, 2022
@janvorlijanvorli added os-windows arch-x64 Servicing-consider Issue for next servicing release review labels Sep 30, 2022
@jkotas

jkotas commented Sep 30, 2022

Copy link
Copy Markdown
Member

Local testing with Visual Studio, monitoring the state of the target process using non-invasively attached WinDbg at the same time and comparing the behavior with .NET 6.

It may be a good idea to ask Visual Studio to run their test suite on this fix.

@jkotas

jkotas commented Sep 30, 2022

Copy link
Copy Markdown
Member

Very low, it touches only the hardware exception handling path and influences only the debugger behavior.

Nit: I would not characterize the risk as very low. The test coverage for these areas is not great and this is not the first regression we are fixing after the recent hardware exception handling changes.

jeffschwMSFT
jeffschwMSFT approved these changes Sep 30, 2022
View reviewed changes

@jeffschwMSFTjeffschwMSFT left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approved. we will take for consideration in 7 ga.

@tommcdon
tommcdon self-requested a review September 30, 2022 14:43
@jeffschwMSFTjeffschwMSFT added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Sep 30, 2022
@carlossanlop

carlossanlop commented Sep 30, 2022

Copy link
Copy Markdown
Contributor

Approved, signed off, CI green. :shipit:

@carlossanlop
carlossanlop merged commit 0a09c8f into release/7.0Sep 30, 2022
@carlossanlop
carlossanlop deleted the backport/pr-76401-to-release/7.0 branch September 30, 2022 21:31
@ghostghost locked as resolved and limited conversation to collaborators Oct 31, 2022
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@jkotasjkotasjkotas approved these changes
@jeffschwMSFTjeffschwMSFTjeffschwMSFT approved these changes
@tommcdontommcdontommcdon approved these changes
@hoyosjshoyosjshoyosjs approved these changes

Assignees

@janvorlijanvorli

Labels

arch-x64area-ExceptionHandling-coreclronly use for closed issuesos-windowsServicing-approvedApproved for servicing release

Projects

None yet

Milestone

7.0.0

Development

Successfully merging this pull request may close these issues.

6 participants

@jkotas@carlossanlop@jeffschwMSFT@tommcdon@hoyosjs@janvorli
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
[release/7.0] Fix edit and continue in VS with hardware exceptions by github-actions[bot] · Pull Request #76427 · dotnet/runtime · GitHub
Skip to content
[release/7.0] Fix edit and continue in VS with hardware exceptions - #76427
Merged
carlossanlop merged 1 commit into
release/7.0from 
backport/pr-76401-to-release/7.0
Sep 30, 2022
Merged
[release/7.0] Fix edit and continue in VS with hardware exceptions#76427
carlossanlop merged 1 commit into
release/7.0from 
backport/pr-76401-to-release/7.0
Conversation
@github-actions
@github-actionsgithub-actionsBot
commented
Sep 30, 2022•

edited by jkotas

Loading

Copy link


Copy Markdown

Contributor
Backport of #76401 to release/7.0
/cc @janvorli
Customer Impact
Without this fix, using the "unwind to this frame" functionality in Visual Studio after a hardware exception like null reference causes the debugged process to crash.
Testing
Local testing with Visual Studio, monitoring the state of the target process using non-invasively attached WinDbg at the same time and comparing the behavior with .NET 6.
Risk
Very low, it touches only the hardware exception handling path and influences only the debugger behavior.
@janvorli
Fix edit and continue in VS with hardware exceptions
0fb9b84
There is a subtle bug in hardware exception handling in the runtime
that causes the debugged process to crash when a user tries to use the
"unwind to this frame" on the frame where the exception happened.
This issue was introduced by the recent changes that modified hardware
exception handling.
The problem turned out to be in how we update the exception and context
records in the HandleManagedFaultFilter when we re-raise the exception
using RaiseException from the VEH. Updating the context is both not
necessary and wrong. All we need to update is the `ExceptionAddress` in
the `EXCEPTION_RECORD`, since the RaiseException puts the address of
itself there and we need the address of the original access violation to
be there.
The context should stay untouched as we are unwinding from the
RaiseException.
The context copying was originally made to mimick the code in the
`NakedThrowHelper` used before the exception handling change. That one
needed the context update, as it was used to fix unwinding over the
NakedThrowHelper that was a hijack helper. In the current state, nothing
like that is needed.
With this fix, the VS debugger works as expected.
@ghostghost
added
the 
area-ExceptionHandling-coreclr
only use for closed issues
label
Sep 30, 2022
@janvorlijanvorli
self-assigned this
Sep 30, 2022
@janvorlijanvorli
added this to the 7.0.0 milestone
Sep 30, 2022
@janvorlijanvorli
added

os-windows

arch-x64

Servicing-consider
Issue for next servicing release review
labels
Sep 30, 2022
@jkotas
jkotas
commented
Sep 30, 2022

Copy link


Copy Markdown

Member
Local testing with Visual Studio, monitoring the state of the target process using non-invasively attached WinDbg at the same time and comparing the behavior with .NET 6.
It may be a good idea to ask Visual Studio to run their test suite on this fix.
@jkotas
jkotas
commented
Sep 30, 2022

Copy link


Copy Markdown

Member
Very low, it touches only the hardware exception handling path and influences only the debugger behavior.
Nit: I would not characterize the risk as very low. The test coverage for these areas is not great and this is not the first regression we are fixing after the recent hardware exception handling changes.
jeffschwMSFT
jeffschwMSFT
approved these changes
Sep 30, 2022
View reviewed changes
@jeffschwMSFTjeffschwMSFT
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approved. we will take for consideration in 7 ga.
@tommcdon
tommcdon
self-requested a review
September 30, 2022 14:43
@jeffschwMSFTjeffschwMSFT
added

Servicing-approved
Approved for servicing release
and removed

Servicing-consider
Issue for next servicing release review
labels
Sep 30, 2022
@carlossanlop
carlossanlop
commented
Sep 30, 2022

Copy link


Copy Markdown

Contributor
Approved, signed off, CI green. :shipit:
@carlossanlop
carlossanlop
merged commit 0a09c8f
into
release/7.0Sep 30, 2022
@carlossanlop
carlossanlop
deleted the

backport/pr-76401-to-release/7.0

branch
September 30, 2022 21:31
@ghostghost
locked as resolved and limited conversation to collaborators
Oct 31, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@jkotasjkotasjkotas approved these changes
@jeffschwMSFTjeffschwMSFTjeffschwMSFT approved these changes
@tommcdontommcdontommcdon approved these changes
@hoyosjshoyosjshoyosjs approved these changes

Assignees

@janvorlijanvorli

Labels

arch-x64area-ExceptionHandling-coreclronly use for closed issuesos-windowsServicing-approvedApproved for servicing release

Projects


None yet


Milestone

7.0.0

Development

Successfully merging this pull request may close these issues.

6 participants

@jkotas@carlossanlop@jeffschwMSFT@tommcdon@hoyosjs@janvorli

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[release/7.0] Fix edit and continue in VS with hardware exceptions by github-actions[bot] · Pull Request #76427 · dotnet/runtime · GitHub
Skip to content
[release/7.0] Fix edit and continue in VS with hardware exceptions - #76427
Merged
carlossanlop merged 1 commit into
release/7.0from 
backport/pr-76401-to-release/7.0
Sep 30, 2022
Merged
[release/7.0] Fix edit and continue in VS with hardware exceptions#76427
carlossanlop merged 1 commit into
release/7.0from 
backport/pr-76401-to-release/7.0
Conversation
@github-actions
@github-actionsgithub-actionsBot
commented
Sep 30, 2022•

edited by jkotas

Loading

Copy link


Copy Markdown

Contributor
Backport of #76401 to release/7.0
/cc @janvorli
Customer Impact
Without this fix, using the "unwind to this frame" functionality in Visual Studio after a hardware exception like null reference causes the debugged process to crash.
Testing
Local testing with Visual Studio, monitoring the state of the target process using non-invasively attached WinDbg at the same time and comparing the behavior with .NET 6.
Risk
Very low, it touches only the hardware exception handling path and influences only the debugger behavior.
@janvorli
Fix edit and continue in VS with hardware exceptions
0fb9b84
There is a subtle bug in hardware exception handling in the runtime
that causes the debugged process to crash when a user tries to use the
"unwind to this frame" on the frame where the exception happened.
This issue was introduced by the recent changes that modified hardware
exception handling.
The problem turned out to be in how we update the exception and context
records in the HandleManagedFaultFilter when we re-raise the exception
using RaiseException from the VEH. Updating the context is both not
necessary and wrong. All we need to update is the `ExceptionAddress` in
the `EXCEPTION_RECORD`, since the RaiseException puts the address of
itself there and we need the address of the original access violation to
be there.
The context should stay untouched as we are unwinding from the
RaiseException.
The context copying was originally made to mimick the code in the
`NakedThrowHelper` used before the exception handling change. That one
needed the context update, as it was used to fix unwinding over the
NakedThrowHelper that was a hijack helper. In the current state, nothing
like that is needed.
With this fix, the VS debugger works as expected.
@ghostghost
added
the 
area-ExceptionHandling-coreclr
only use for closed issues
label
Sep 30, 2022
@janvorlijanvorli
self-assigned this
Sep 30, 2022
@janvorlijanvorli
added this to the 7.0.0 milestone
Sep 30, 2022
@janvorlijanvorli
added

os-windows

arch-x64

Servicing-consider
Issue for next servicing release review
labels
Sep 30, 2022
@jkotas
jkotas
commented
Sep 30, 2022

Copy link


Copy Markdown

Member
Local testing with Visual Studio, monitoring the state of the target process using non-invasively attached WinDbg at the same time and comparing the behavior with .NET 6.
It may be a good idea to ask Visual Studio to run their test suite on this fix.
@jkotas
jkotas
commented
Sep 30, 2022

Copy link


Copy Markdown

Member
Very low, it touches only the hardware exception handling path and influences only the debugger behavior.
Nit: I would not characterize the risk as very low. The test coverage for these areas is not great and this is not the first regression we are fixing after the recent hardware exception handling changes.
jeffschwMSFT
jeffschwMSFT
approved these changes
Sep 30, 2022
View reviewed changes
@jeffschwMSFTjeffschwMSFT
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approved. we will take for consideration in 7 ga.
@tommcdon
tommcdon
self-requested a review
September 30, 2022 14:43
@jeffschwMSFTjeffschwMSFT
added

Servicing-approved
Approved for servicing release
and removed

Servicing-consider
Issue for next servicing release review
labels
Sep 30, 2022
@carlossanlop
carlossanlop
commented
Sep 30, 2022

Copy link


Copy Markdown

Contributor
Approved, signed off, CI green. :shipit:
@carlossanlop
carlossanlop
merged commit 0a09c8f
into
release/7.0Sep 30, 2022
@carlossanlop
carlossanlop
deleted the

backport/pr-76401-to-release/7.0

branch
September 30, 2022 21:31
@ghostghost
locked as resolved and limited conversation to collaborators
Oct 31, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@jkotasjkotasjkotas approved these changes
@jeffschwMSFTjeffschwMSFTjeffschwMSFT approved these changes
@tommcdontommcdontommcdon approved these changes
@hoyosjshoyosjshoyosjs approved these changes

Assignees

@janvorlijanvorli

Labels

arch-x64area-ExceptionHandling-coreclronly use for closed issuesos-windowsServicing-approvedApproved for servicing release

Projects


None yet


Milestone

7.0.0

Development

Successfully merging this pull request may close these issues.

6 participants

@jkotas@carlossanlop@jeffschwMSFT@tommcdon@hoyosjs@janvorli

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[release/7.0] Fix edit and continue in VS with hardware exceptions by github-actions[bot] · Pull Request #76427 · dotnet/runtime · GitHub
Skip to content
[release/7.0] Fix edit and continue in VS with hardware exceptions - #76427
Merged
carlossanlop merged 1 commit into
release/7.0from 
backport/pr-76401-to-release/7.0
Sep 30, 2022
Merged
[release/7.0] Fix edit and continue in VS with hardware exceptions#76427
carlossanlop merged 1 commit into
release/7.0from 
backport/pr-76401-to-release/7.0
Conversation
@github-actions
@github-actionsgithub-actionsBot
commented
Sep 30, 2022•

edited by jkotas

Loading

Copy link


Copy Markdown

Contributor
Backport of #76401 to release/7.0
/cc @janvorli
Customer Impact
Without this fix, using the "unwind to this frame" functionality in Visual Studio after a hardware exception like null reference causes the debugged process to crash.
Testing
Local testing with Visual Studio, monitoring the state of the target process using non-invasively attached WinDbg at the same time and comparing the behavior with .NET 6.
Risk
Very low, it touches only the hardware exception handling path and influences only the debugger behavior.
@janvorli
Fix edit and continue in VS with hardware exceptions
0fb9b84
There is a subtle bug in hardware exception handling in the runtime
that causes the debugged process to crash when a user tries to use the
"unwind to this frame" on the frame where the exception happened.
This issue was introduced by the recent changes that modified hardware
exception handling.
The problem turned out to be in how we update the exception and context
records in the HandleManagedFaultFilter when we re-raise the exception
using RaiseException from the VEH. Updating the context is both not
necessary and wrong. All we need to update is the `ExceptionAddress` in
the `EXCEPTION_RECORD`, since the RaiseException puts the address of
itself there and we need the address of the original access violation to
be there.
The context should stay untouched as we are unwinding from the
RaiseException.
The context copying was originally made to mimick the code in the
`NakedThrowHelper` used before the exception handling change. That one
needed the context update, as it was used to fix unwinding over the
NakedThrowHelper that was a hijack helper. In the current state, nothing
like that is needed.
With this fix, the VS debugger works as expected.
@ghostghost
added
the 
area-ExceptionHandling-coreclr
only use for closed issues
label
Sep 30, 2022
@janvorlijanvorli
self-assigned this
Sep 30, 2022
@janvorlijanvorli
added this to the 7.0.0 milestone
Sep 30, 2022
@janvorlijanvorli
added

os-windows

arch-x64

Servicing-consider
Issue for next servicing release review
labels
Sep 30, 2022
@jkotas
jkotas
commented
Sep 30, 2022

Copy link


Copy Markdown

Member
Local testing with Visual Studio, monitoring the state of the target process using non-invasively attached WinDbg at the same time and comparing the behavior with .NET 6.
It may be a good idea to ask Visual Studio to run their test suite on this fix.
@jkotas
jkotas
commented
Sep 30, 2022

Copy link


Copy Markdown

Member
Very low, it touches only the hardware exception handling path and influences only the debugger behavior.
Nit: I would not characterize the risk as very low. The test coverage for these areas is not great and this is not the first regression we are fixing after the recent hardware exception handling changes.
jeffschwMSFT
jeffschwMSFT
approved these changes
Sep 30, 2022
View reviewed changes
@jeffschwMSFTjeffschwMSFT
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approved. we will take for consideration in 7 ga.
@tommcdon
tommcdon
self-requested a review
September 30, 2022 14:43
@jeffschwMSFTjeffschwMSFT
added

Servicing-approved
Approved for servicing release
and removed

Servicing-consider
Issue for next servicing release review
labels
Sep 30, 2022
@carlossanlop
carlossanlop
commented
Sep 30, 2022

Copy link


Copy Markdown

Contributor
Approved, signed off, CI green. :shipit:
@carlossanlop
carlossanlop
merged commit 0a09c8f
into
release/7.0Sep 30, 2022
@carlossanlop
carlossanlop
deleted the

backport/pr-76401-to-release/7.0

branch
September 30, 2022 21:31
@ghostghost
locked as resolved and limited conversation to collaborators
Oct 31, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@jkotasjkotasjkotas approved these changes
@jeffschwMSFTjeffschwMSFTjeffschwMSFT approved these changes
@tommcdontommcdontommcdon approved these changes
@hoyosjshoyosjshoyosjs approved these changes

Assignees

@janvorlijanvorli

Labels

arch-x64area-ExceptionHandling-coreclronly use for closed issuesos-windowsServicing-approvedApproved for servicing release

Projects


None yet


Milestone

7.0.0

Development

Successfully merging this pull request may close these issues.

6 participants

@jkotas@carlossanlop@jeffschwMSFT@tommcdon@hoyosjs@janvorli

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
[release/7.0] Fix edit and continue in VS with hardware exceptions by github-actions[bot] · Pull Request #76427 · dotnet/runtime · GitHub
Skip to content
[release/7.0] Fix edit and continue in VS with hardware exceptions - #76427
Merged
carlossanlop merged 1 commit into
release/7.0from 
backport/pr-76401-to-release/7.0
Sep 30, 2022
Merged
[release/7.0] Fix edit and continue in VS with hardware exceptions#76427
carlossanlop merged 1 commit into
release/7.0from 
backport/pr-76401-to-release/7.0
Conversation
@github-actions
@github-actionsgithub-actionsBot
commented
Sep 30, 2022•

edited by jkotas

Loading

Copy link


Copy Markdown

Contributor
Backport of #76401 to release/7.0
/cc @janvorli
Customer Impact
Without this fix, using the "unwind to this frame" functionality in Visual Studio after a hardware exception like null reference causes the debugged process to crash.
Testing
Local testing with Visual Studio, monitoring the state of the target process using non-invasively attached WinDbg at the same time and comparing the behavior with .NET 6.
Risk
Very low, it touches only the hardware exception handling path and influences only the debugger behavior.
@janvorli
Fix edit and continue in VS with hardware exceptions
0fb9b84
There is a subtle bug in hardware exception handling in the runtime
that causes the debugged process to crash when a user tries to use the
"unwind to this frame" on the frame where the exception happened.
This issue was introduced by the recent changes that modified hardware
exception handling.
The problem turned out to be in how we update the exception and context
records in the HandleManagedFaultFilter when we re-raise the exception
using RaiseException from the VEH. Updating the context is both not
necessary and wrong. All we need to update is the `ExceptionAddress` in
the `EXCEPTION_RECORD`, since the RaiseException puts the address of
itself there and we need the address of the original access violation to
be there.
The context should stay untouched as we are unwinding from the
RaiseException.
The context copying was originally made to mimick the code in the
`NakedThrowHelper` used before the exception handling change. That one
needed the context update, as it was used to fix unwinding over the
NakedThrowHelper that was a hijack helper. In the current state, nothing
like that is needed.
With this fix, the VS debugger works as expected.
@ghostghost
added
the 
area-ExceptionHandling-coreclr
only use for closed issues
label
Sep 30, 2022
@janvorlijanvorli
self-assigned this
Sep 30, 2022
@janvorlijanvorli
added this to the 7.0.0 milestone
Sep 30, 2022
@janvorlijanvorli
added

os-windows

arch-x64

Servicing-consider
Issue for next servicing release review
labels
Sep 30, 2022
@jkotas
jkotas
commented
Sep 30, 2022

Copy link


Copy Markdown

Member
Local testing with Visual Studio, monitoring the state of the target process using non-invasively attached WinDbg at the same time and comparing the behavior with .NET 6.
It may be a good idea to ask Visual Studio to run their test suite on this fix.
@jkotas
jkotas
commented
Sep 30, 2022

Copy link


Copy Markdown

Member
Very low, it touches only the hardware exception handling path and influences only the debugger behavior.
Nit: I would not characterize the risk as very low. The test coverage for these areas is not great and this is not the first regression we are fixing after the recent hardware exception handling changes.
jeffschwMSFT
jeffschwMSFT
approved these changes
Sep 30, 2022
View reviewed changes
@jeffschwMSFTjeffschwMSFT
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approved. we will take for consideration in 7 ga.
@tommcdon
tommcdon
self-requested a review
September 30, 2022 14:43
@jeffschwMSFTjeffschwMSFT
added

Servicing-approved
Approved for servicing release
and removed

Servicing-consider
Issue for next servicing release review
labels
Sep 30, 2022
@carlossanlop
carlossanlop
commented
Sep 30, 2022

Copy link


Copy Markdown

Contributor
Approved, signed off, CI green. :shipit:
@carlossanlop
carlossanlop
merged commit 0a09c8f
into
release/7.0Sep 30, 2022
@carlossanlop
carlossanlop
deleted the

backport/pr-76401-to-release/7.0

branch
September 30, 2022 21:31
@ghostghost
locked as resolved and limited conversation to collaborators
Oct 31, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@jkotasjkotasjkotas approved these changes
@jeffschwMSFTjeffschwMSFTjeffschwMSFT approved these changes
@tommcdontommcdontommcdon approved these changes
@hoyosjshoyosjshoyosjs approved these changes

Assignees

@janvorlijanvorli

Labels

arch-x64area-ExceptionHandling-coreclronly use for closed issuesos-windowsServicing-approvedApproved for servicing release

Projects


None yet


Milestone

7.0.0

Development

Successfully merging this pull request may close these issues.

6 participants

@jkotas@carlossanlop@jeffschwMSFT@tommcdon@hoyosjs@janvorli

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
[release/7.0] Fix edit and continue in VS with hardware exceptions by github-actions[bot] · Pull Request #76427 · dotnet/runtime · GitHub
Skip to content
[release/7.0] Fix edit and continue in VS with hardware exceptions - #76427
Merged
carlossanlop merged 1 commit into
release/7.0from 
backport/pr-76401-to-release/7.0
Sep 30, 2022
Merged
[release/7.0] Fix edit and continue in VS with hardware exceptions#76427
carlossanlop merged 1 commit into
release/7.0from 
backport/pr-76401-to-release/7.0
Conversation
@github-actions
@github-actionsgithub-actionsBot
commented
Sep 30, 2022•

edited by jkotas

Loading

Copy link


Copy Markdown

Contributor
Backport of #76401 to release/7.0
/cc @janvorli
Customer Impact
Without this fix, using the "unwind to this frame" functionality in Visual Studio after a hardware exception like null reference causes the debugged process to crash.
Testing
Local testing with Visual Studio, monitoring the state of the target process using non-invasively attached WinDbg at the same time and comparing the behavior with .NET 6.
Risk
Very low, it touches only the hardware exception handling path and influences only the debugger behavior.
@janvorli
Fix edit and continue in VS with hardware exceptions
0fb9b84
There is a subtle bug in hardware exception handling in the runtime
that causes the debugged process to crash when a user tries to use the
"unwind to this frame" on the frame where the exception happened.
This issue was introduced by the recent changes that modified hardware
exception handling.
The problem turned out to be in how we update the exception and context
records in the HandleManagedFaultFilter when we re-raise the exception
using RaiseException from the VEH. Updating the context is both not
necessary and wrong. All we need to update is the `ExceptionAddress` in
the `EXCEPTION_RECORD`, since the RaiseException puts the address of
itself there and we need the address of the original access violation to
be there.
The context should stay untouched as we are unwinding from the
RaiseException.
The context copying was originally made to mimick the code in the
`NakedThrowHelper` used before the exception handling change. That one
needed the context update, as it was used to fix unwinding over the
NakedThrowHelper that was a hijack helper. In the current state, nothing
like that is needed.
With this fix, the VS debugger works as expected.
@ghostghost
added
the 
area-ExceptionHandling-coreclr
only use for closed issues
label
Sep 30, 2022
@janvorlijanvorli
self-assigned this
Sep 30, 2022
@janvorlijanvorli
added this to the 7.0.0 milestone
Sep 30, 2022
@janvorlijanvorli
added

os-windows

arch-x64

Servicing-consider
Issue for next servicing release review
labels
Sep 30, 2022
@jkotas
jkotas
commented
Sep 30, 2022

Copy link


Copy Markdown

Member
Local testing with Visual Studio, monitoring the state of the target process using non-invasively attached WinDbg at the same time and comparing the behavior with .NET 6.
It may be a good idea to ask Visual Studio to run their test suite on this fix.
@jkotas
jkotas
commented
Sep 30, 2022

Copy link


Copy Markdown

Member
Very low, it touches only the hardware exception handling path and influences only the debugger behavior.
Nit: I would not characterize the risk as very low. The test coverage for these areas is not great and this is not the first regression we are fixing after the recent hardware exception handling changes.
jeffschwMSFT
jeffschwMSFT
approved these changes
Sep 30, 2022
View reviewed changes
@jeffschwMSFTjeffschwMSFT
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approved. we will take for consideration in 7 ga.
@tommcdon
tommcdon
self-requested a review
September 30, 2022 14:43
@jeffschwMSFTjeffschwMSFT
added

Servicing-approved
Approved for servicing release
and removed

Servicing-consider
Issue for next servicing release review
labels
Sep 30, 2022
@carlossanlop
carlossanlop
commented
Sep 30, 2022

Copy link


Copy Markdown

Contributor
Approved, signed off, CI green. :shipit:
@carlossanlop
carlossanlop
merged commit 0a09c8f
into
release/7.0Sep 30, 2022
@carlossanlop
carlossanlop
deleted the

backport/pr-76401-to-release/7.0

branch
September 30, 2022 21:31
@ghostghost
locked as resolved and limited conversation to collaborators
Oct 31, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@jkotasjkotasjkotas approved these changes
@jeffschwMSFTjeffschwMSFTjeffschwMSFT approved these changes
@tommcdontommcdontommcdon approved these changes
@hoyosjshoyosjshoyosjs approved these changes

Assignees

@janvorlijanvorli

Labels

arch-x64area-ExceptionHandling-coreclronly use for closed issuesos-windowsServicing-approvedApproved for servicing release

Projects


None yet


Milestone

7.0.0

Development

Successfully merging this pull request may close these issues.

6 participants

@jkotas@carlossanlop@jeffschwMSFT@tommcdon@hoyosjs@janvorli

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
})();
[release/7.0] Fix edit and continue in VS with hardware exceptions by github-actions[bot] · Pull Request #76427 · dotnet/runtime · GitHub
Skip to content
[release/7.0] Fix edit and continue in VS with hardware exceptions - #76427
Merged
carlossanlop merged 1 commit into
release/7.0from 
backport/pr-76401-to-release/7.0
Sep 30, 2022
Merged
[release/7.0] Fix edit and continue in VS with hardware exceptions#76427
carlossanlop merged 1 commit into
release/7.0from 
backport/pr-76401-to-release/7.0
Conversation
@github-actions
@github-actionsgithub-actionsBot
commented
Sep 30, 2022•

edited by jkotas

Loading

Copy link


Copy Markdown

Contributor
Backport of #76401 to release/7.0
/cc @janvorli
Customer Impact
Without this fix, using the "unwind to this frame" functionality in Visual Studio after a hardware exception like null reference causes the debugged process to crash.
Testing
Local testing with Visual Studio, monitoring the state of the target process using non-invasively attached WinDbg at the same time and comparing the behavior with .NET 6.
Risk
Very low, it touches only the hardware exception handling path and influences only the debugger behavior.
@janvorli
Fix edit and continue in VS with hardware exceptions
0fb9b84
There is a subtle bug in hardware exception handling in the runtime
that causes the debugged process to crash when a user tries to use the
"unwind to this frame" on the frame where the exception happened.
This issue was introduced by the recent changes that modified hardware
exception handling.
The problem turned out to be in how we update the exception and context
records in the HandleManagedFaultFilter when we re-raise the exception
using RaiseException from the VEH. Updating the context is both not
necessary and wrong. All we need to update is the `ExceptionAddress` in
the `EXCEPTION_RECORD`, since the RaiseException puts the address of
itself there and we need the address of the original access violation to
be there.
The context should stay untouched as we are unwinding from the
RaiseException.
The context copying was originally made to mimick the code in the
`NakedThrowHelper` used before the exception handling change. That one
needed the context update, as it was used to fix unwinding over the
NakedThrowHelper that was a hijack helper. In the current state, nothing
like that is needed.
With this fix, the VS debugger works as expected.
@ghostghost
added
the 
area-ExceptionHandling-coreclr
only use for closed issues
label
Sep 30, 2022
@janvorlijanvorli
self-assigned this
Sep 30, 2022
@janvorlijanvorli
added this to the 7.0.0 milestone
Sep 30, 2022
@janvorlijanvorli
added

os-windows

arch-x64

Servicing-consider
Issue for next servicing release review
labels
Sep 30, 2022
@jkotas
jkotas
commented
Sep 30, 2022

Copy link


Copy Markdown

Member
Local testing with Visual Studio, monitoring the state of the target process using non-invasively attached WinDbg at the same time and comparing the behavior with .NET 6.
It may be a good idea to ask Visual Studio to run their test suite on this fix.
@jkotas
jkotas
commented
Sep 30, 2022

Copy link


Copy Markdown

Member
Very low, it touches only the hardware exception handling path and influences only the debugger behavior.
Nit: I would not characterize the risk as very low. The test coverage for these areas is not great and this is not the first regression we are fixing after the recent hardware exception handling changes.
jeffschwMSFT
jeffschwMSFT
approved these changes
Sep 30, 2022
View reviewed changes
@jeffschwMSFTjeffschwMSFT
left a comment


Copy link


Copy Markdown

Member
Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approved. we will take for consideration in 7 ga.
@tommcdon
tommcdon
self-requested a review
September 30, 2022 14:43
@jeffschwMSFTjeffschwMSFT
added

Servicing-approved
Approved for servicing release
and removed

Servicing-consider
Issue for next servicing release review
labels
Sep 30, 2022
@carlossanlop
carlossanlop
commented
Sep 30, 2022

Copy link


Copy Markdown

Contributor
Approved, signed off, CI green. :shipit:
@carlossanlop
carlossanlop
merged commit 0a09c8f
into
release/7.0Sep 30, 2022
@carlossanlop
carlossanlop
deleted the

backport/pr-76401-to-release/7.0

branch
September 30, 2022 21:31
@ghostghost
locked as resolved and limited conversation to collaborators
Oct 31, 2022
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@jkotasjkotasjkotas approved these changes
@jeffschwMSFTjeffschwMSFTjeffschwMSFT approved these changes
@tommcdontommcdontommcdon approved these changes
@hoyosjshoyosjshoyosjs approved these changes

Assignees

@janvorlijanvorli

Labels

arch-x64area-ExceptionHandling-coreclronly use for closed issuesos-windowsServicing-approvedApproved for servicing release

Projects


None yet


Milestone

7.0.0

Development

Successfully merging this pull request may close these issues.

6 participants

@jkotas@carlossanlop@jeffschwMSFT@tommcdon@hoyosjs@janvorli