Skip to content

Fix edit and continue in VS with hardware exceptions - #76401

Merged
janvorli merged 1 commit into
dotnet:mainfrom
janvorli:fix-hardware-exception-edit-and-continue
Sep 30, 2022
Merged

Fix edit and continue in VS with hardware exceptions#76401
janvorli merged 1 commit into
dotnet:mainfrom
janvorli:fix-hardware-exception-edit-and-continue

Conversation

@janvorli

@janvorlijanvorli commented Sep 29, 2022

Copy link
Copy Markdown
Member

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.

Close#75762

@janvorli
Fix edit and continue in VS with hardware exceptions
d75309d
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.
@janvorlijanvorli added the area-ExceptionHandling-coreclr only use for closed issues label Sep 29, 2022
@janvorlijanvorli added this to the 7.0.0 milestone Sep 29, 2022
@janvorlijanvorli self-assigned this Sep 29, 2022
@janvorli

janvorli commented Sep 29, 2022

Copy link
Copy Markdown
MemberAuthor

cc: @tommcdon, @hoyosjs

@janvorli
janvorli merged commit 062fb45 into dotnet:mainSep 30, 2022
@janvorli

janvorli commented Sep 30, 2022

Copy link
Copy Markdown
MemberAuthor

/backport to release/7.0

@github-actions

github-actionsBot commented Sep 30, 2022

Copy link
Copy Markdown
Contributor

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3157197640

@github-actionsgithub-actionsBot mentioned this pull request Sep 30, 2022
Merged
@ghostghost locked as resolved and limited conversation to collaborators Oct 30, 2022
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@jkotasjkotasjkotas approved these changes
@hoyosjshoyosjsAwaiting requested review from hoyosjs
@noahfalknoahfalkAwaiting requested review from noahfalk

Assignees

@janvorlijanvorli

Labels

area-ExceptionHandling-coreclronly use for closed issues

Projects

None yet

Milestone

7.0.0

Development

Successfully merging this pull request may close these issues.

ICorDebugThread2.InterceptCurrentException corrupts process in x64 Windows

2 participants

@janvorli@jkotas
, '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" + '
Fix edit and continue in VS with hardware exceptions by janvorli · Pull Request #76401 · dotnet/runtime · GitHub
Skip to content
Fix edit and continue in VS with hardware exceptions - #76401
Merged
janvorli merged 1 commit into
dotnet:mainfrom 
janvorli:fix-hardware-exception-edit-and-continue
Sep 30, 2022
Merged
Fix edit and continue in VS with hardware exceptions#76401
janvorli merged 1 commit into
dotnet:mainfrom 
janvorli:fix-hardware-exception-edit-and-continue
Conversation
@janvorli
@janvorlijanvorli
commented
Sep 29, 2022

Copy link


Copy Markdown

Member
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.
Close#75762
@janvorli
Fix edit and continue in VS with hardware exceptions
d75309d
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.
@janvorlijanvorli
added
the 
area-ExceptionHandling-coreclr
only use for closed issues
label
Sep 29, 2022
@janvorlijanvorli
added this to the 7.0.0 milestone
Sep 29, 2022
@janvorlijanvorli
self-assigned this
Sep 29, 2022
@janvorli
janvorli
commented
Sep 29, 2022

Copy link


Copy Markdown

MemberAuthor
cc: @tommcdon, @hoyosjs
@janvorli
janvorli
merged commit 062fb45
into
dotnet:mainSep 30, 2022
@janvorli
janvorli
commented
Sep 30, 2022

Copy link


Copy Markdown

MemberAuthor
/backport to release/7.0
@github-actions
github-actionsBot
commented
Sep 30, 2022

Copy link


Copy Markdown

Contributor
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3157197640
@github-actionsgithub-actionsBot
mentioned this pull request
Sep 30, 2022
 Merged

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


Reviewers

@jkotasjkotasjkotas approved these changes
@hoyosjshoyosjsAwaiting requested review from hoyosjs
@noahfalknoahfalkAwaiting requested review from noahfalk

Assignees

@janvorlijanvorli

Labels

area-ExceptionHandling-coreclronly use for closed issues

Projects


None yet


Milestone

7.0.0

Development

Successfully merging this pull request may close these issues.

ICorDebugThread2.InterceptCurrentException corrupts process in x64 Windows


2 participants

@janvorli@jkotas

, '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('^' + ".*" + '
Fix edit and continue in VS with hardware exceptions by janvorli · Pull Request #76401 · dotnet/runtime · GitHub
Skip to content
Fix edit and continue in VS with hardware exceptions - #76401
Merged
janvorli merged 1 commit into
dotnet:mainfrom 
janvorli:fix-hardware-exception-edit-and-continue
Sep 30, 2022
Merged
Fix edit and continue in VS with hardware exceptions#76401
janvorli merged 1 commit into
dotnet:mainfrom 
janvorli:fix-hardware-exception-edit-and-continue
Conversation
@janvorli
@janvorlijanvorli
commented
Sep 29, 2022

Copy link


Copy Markdown

Member
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.
Close#75762
@janvorli
Fix edit and continue in VS with hardware exceptions
d75309d
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.
@janvorlijanvorli
added
the 
area-ExceptionHandling-coreclr
only use for closed issues
label
Sep 29, 2022
@janvorlijanvorli
added this to the 7.0.0 milestone
Sep 29, 2022
@janvorlijanvorli
self-assigned this
Sep 29, 2022
@janvorli
janvorli
commented
Sep 29, 2022

Copy link


Copy Markdown

MemberAuthor
cc: @tommcdon, @hoyosjs
@janvorli
janvorli
merged commit 062fb45
into
dotnet:mainSep 30, 2022
@janvorli
janvorli
commented
Sep 30, 2022

Copy link


Copy Markdown

MemberAuthor
/backport to release/7.0
@github-actions
github-actionsBot
commented
Sep 30, 2022

Copy link


Copy Markdown

Contributor
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3157197640
@github-actionsgithub-actionsBot
mentioned this pull request
Sep 30, 2022
 Merged

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


Reviewers

@jkotasjkotasjkotas approved these changes
@hoyosjshoyosjsAwaiting requested review from hoyosjs
@noahfalknoahfalkAwaiting requested review from noahfalk

Assignees

@janvorlijanvorli

Labels

area-ExceptionHandling-coreclronly use for closed issues

Projects


None yet


Milestone

7.0.0

Development

Successfully merging this pull request may close these issues.

ICorDebugThread2.InterceptCurrentException corrupts process in x64 Windows


2 participants

@janvorli@jkotas

, '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('^' + ".*" + '
Fix edit and continue in VS with hardware exceptions by janvorli · Pull Request #76401 · dotnet/runtime · GitHub
Skip to content
Fix edit and continue in VS with hardware exceptions - #76401
Merged
janvorli merged 1 commit into
dotnet:mainfrom 
janvorli:fix-hardware-exception-edit-and-continue
Sep 30, 2022
Merged
Fix edit and continue in VS with hardware exceptions#76401
janvorli merged 1 commit into
dotnet:mainfrom 
janvorli:fix-hardware-exception-edit-and-continue
Conversation
@janvorli
@janvorlijanvorli
commented
Sep 29, 2022

Copy link


Copy Markdown

Member
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.
Close#75762
@janvorli
Fix edit and continue in VS with hardware exceptions
d75309d
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.
@janvorlijanvorli
added
the 
area-ExceptionHandling-coreclr
only use for closed issues
label
Sep 29, 2022
@janvorlijanvorli
added this to the 7.0.0 milestone
Sep 29, 2022
@janvorlijanvorli
self-assigned this
Sep 29, 2022
@janvorli
janvorli
commented
Sep 29, 2022

Copy link


Copy Markdown

MemberAuthor
cc: @tommcdon, @hoyosjs
@janvorli
janvorli
merged commit 062fb45
into
dotnet:mainSep 30, 2022
@janvorli
janvorli
commented
Sep 30, 2022

Copy link


Copy Markdown

MemberAuthor
/backport to release/7.0
@github-actions
github-actionsBot
commented
Sep 30, 2022

Copy link


Copy Markdown

Contributor
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3157197640
@github-actionsgithub-actionsBot
mentioned this pull request
Sep 30, 2022
 Merged

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


Reviewers

@jkotasjkotasjkotas approved these changes
@hoyosjshoyosjsAwaiting requested review from hoyosjs
@noahfalknoahfalkAwaiting requested review from noahfalk

Assignees

@janvorlijanvorli

Labels

area-ExceptionHandling-coreclronly use for closed issues

Projects


None yet


Milestone

7.0.0

Development

Successfully merging this pull request may close these issues.

ICorDebugThread2.InterceptCurrentException corrupts process in x64 Windows


2 participants

@janvorli@jkotas

, '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" + '
Fix edit and continue in VS with hardware exceptions by janvorli · Pull Request #76401 · dotnet/runtime · GitHub
Skip to content
Fix edit and continue in VS with hardware exceptions - #76401
Merged
janvorli merged 1 commit into
dotnet:mainfrom 
janvorli:fix-hardware-exception-edit-and-continue
Sep 30, 2022
Merged
Fix edit and continue in VS with hardware exceptions#76401
janvorli merged 1 commit into
dotnet:mainfrom 
janvorli:fix-hardware-exception-edit-and-continue
Conversation
@janvorli
@janvorlijanvorli
commented
Sep 29, 2022

Copy link


Copy Markdown

Member
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.
Close#75762
@janvorli
Fix edit and continue in VS with hardware exceptions
d75309d
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.
@janvorlijanvorli
added
the 
area-ExceptionHandling-coreclr
only use for closed issues
label
Sep 29, 2022
@janvorlijanvorli
added this to the 7.0.0 milestone
Sep 29, 2022
@janvorlijanvorli
self-assigned this
Sep 29, 2022
@janvorli
janvorli
commented
Sep 29, 2022

Copy link


Copy Markdown

MemberAuthor
cc: @tommcdon, @hoyosjs
@janvorli
janvorli
merged commit 062fb45
into
dotnet:mainSep 30, 2022
@janvorli
janvorli
commented
Sep 30, 2022

Copy link


Copy Markdown

MemberAuthor
/backport to release/7.0
@github-actions
github-actionsBot
commented
Sep 30, 2022

Copy link


Copy Markdown

Contributor
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3157197640
@github-actionsgithub-actionsBot
mentioned this pull request
Sep 30, 2022
 Merged

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


Reviewers

@jkotasjkotasjkotas approved these changes
@hoyosjshoyosjsAwaiting requested review from hoyosjs
@noahfalknoahfalkAwaiting requested review from noahfalk

Assignees

@janvorlijanvorli

Labels

area-ExceptionHandling-coreclronly use for closed issues

Projects


None yet


Milestone

7.0.0

Development

Successfully merging this pull request may close these issues.

ICorDebugThread2.InterceptCurrentException corrupts process in x64 Windows


2 participants

@janvorli@jkotas

, '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('^' + ".*" + '
Fix edit and continue in VS with hardware exceptions by janvorli · Pull Request #76401 · dotnet/runtime · GitHub
Skip to content
Fix edit and continue in VS with hardware exceptions - #76401
Merged
janvorli merged 1 commit into
dotnet:mainfrom 
janvorli:fix-hardware-exception-edit-and-continue
Sep 30, 2022
Merged
Fix edit and continue in VS with hardware exceptions#76401
janvorli merged 1 commit into
dotnet:mainfrom 
janvorli:fix-hardware-exception-edit-and-continue
Conversation
@janvorli
@janvorlijanvorli
commented
Sep 29, 2022

Copy link


Copy Markdown

Member
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.
Close#75762
@janvorli
Fix edit and continue in VS with hardware exceptions
d75309d
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.
@janvorlijanvorli
added
the 
area-ExceptionHandling-coreclr
only use for closed issues
label
Sep 29, 2022
@janvorlijanvorli
added this to the 7.0.0 milestone
Sep 29, 2022
@janvorlijanvorli
self-assigned this
Sep 29, 2022
@janvorli
janvorli
commented
Sep 29, 2022

Copy link


Copy Markdown

MemberAuthor
cc: @tommcdon, @hoyosjs
@janvorli
janvorli
merged commit 062fb45
into
dotnet:mainSep 30, 2022
@janvorli
janvorli
commented
Sep 30, 2022

Copy link


Copy Markdown

MemberAuthor
/backport to release/7.0
@github-actions
github-actionsBot
commented
Sep 30, 2022

Copy link


Copy Markdown

Contributor
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3157197640
@github-actionsgithub-actionsBot
mentioned this pull request
Sep 30, 2022
 Merged

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


Reviewers

@jkotasjkotasjkotas approved these changes
@hoyosjshoyosjsAwaiting requested review from hoyosjs
@noahfalknoahfalkAwaiting requested review from noahfalk

Assignees

@janvorlijanvorli

Labels

area-ExceptionHandling-coreclronly use for closed issues

Projects


None yet


Milestone

7.0.0

Development

Successfully merging this pull request may close these issues.

ICorDebugThread2.InterceptCurrentException corrupts process in x64 Windows


2 participants

@janvorli@jkotas

, '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); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Fix edit and continue in VS with hardware exceptions by janvorli · Pull Request #76401 · dotnet/runtime · GitHub
Skip to content
Fix edit and continue in VS with hardware exceptions - #76401
Merged
janvorli merged 1 commit into
dotnet:mainfrom 
janvorli:fix-hardware-exception-edit-and-continue
Sep 30, 2022
Merged
Fix edit and continue in VS with hardware exceptions#76401
janvorli merged 1 commit into
dotnet:mainfrom 
janvorli:fix-hardware-exception-edit-and-continue
Conversation
@janvorli
@janvorlijanvorli
commented
Sep 29, 2022

Copy link


Copy Markdown

Member
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.
Close#75762
@janvorli
Fix edit and continue in VS with hardware exceptions
d75309d
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.
@janvorlijanvorli
added
the 
area-ExceptionHandling-coreclr
only use for closed issues
label
Sep 29, 2022
@janvorlijanvorli
added this to the 7.0.0 milestone
Sep 29, 2022
@janvorlijanvorli
self-assigned this
Sep 29, 2022
@janvorli
janvorli
commented
Sep 29, 2022

Copy link


Copy Markdown

MemberAuthor
cc: @tommcdon, @hoyosjs
@janvorli
janvorli
merged commit 062fb45
into
dotnet:mainSep 30, 2022
@janvorli
janvorli
commented
Sep 30, 2022

Copy link


Copy Markdown

MemberAuthor
/backport to release/7.0
@github-actions
github-actionsBot
commented
Sep 30, 2022

Copy link


Copy Markdown

Contributor
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3157197640
@github-actionsgithub-actionsBot
mentioned this pull request
Sep 30, 2022
 Merged

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


Reviewers

@jkotasjkotasjkotas approved these changes
@hoyosjshoyosjsAwaiting requested review from hoyosjs
@noahfalknoahfalkAwaiting requested review from noahfalk

Assignees

@janvorlijanvorli

Labels

area-ExceptionHandling-coreclronly use for closed issues

Projects


None yet


Milestone

7.0.0

Development

Successfully merging this pull request may close these issues.

ICorDebugThread2.InterceptCurrentException corrupts process in x64 Windows


2 participants

@janvorli@jkotas

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
Fix edit and continue in VS with hardware exceptions by janvorli · Pull Request #76401 · dotnet/runtime · GitHub
Skip to content
Fix edit and continue in VS with hardware exceptions - #76401
Merged
janvorli merged 1 commit into
dotnet:mainfrom 
janvorli:fix-hardware-exception-edit-and-continue
Sep 30, 2022
Merged
Fix edit and continue in VS with hardware exceptions#76401
janvorli merged 1 commit into
dotnet:mainfrom 
janvorli:fix-hardware-exception-edit-and-continue
Conversation
@janvorli
@janvorlijanvorli
commented
Sep 29, 2022

Copy link


Copy Markdown

Member
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.
Close#75762
@janvorli
Fix edit and continue in VS with hardware exceptions
d75309d
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.
@janvorlijanvorli
added
the 
area-ExceptionHandling-coreclr
only use for closed issues
label
Sep 29, 2022
@janvorlijanvorli
added this to the 7.0.0 milestone
Sep 29, 2022
@janvorlijanvorli
self-assigned this
Sep 29, 2022
@janvorli
janvorli
commented
Sep 29, 2022

Copy link


Copy Markdown

MemberAuthor
cc: @tommcdon, @hoyosjs
@janvorli
janvorli
merged commit 062fb45
into
dotnet:mainSep 30, 2022
@janvorli
janvorli
commented
Sep 30, 2022

Copy link


Copy Markdown

MemberAuthor
/backport to release/7.0
@github-actions
github-actionsBot
commented
Sep 30, 2022

Copy link


Copy Markdown

Contributor
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3157197640
@github-actionsgithub-actionsBot
mentioned this pull request
Sep 30, 2022
 Merged

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


Reviewers

@jkotasjkotasjkotas approved these changes
@hoyosjshoyosjsAwaiting requested review from hoyosjs
@noahfalknoahfalkAwaiting requested review from noahfalk

Assignees

@janvorlijanvorli

Labels

area-ExceptionHandling-coreclronly use for closed issues

Projects


None yet


Milestone

7.0.0

Development

Successfully merging this pull request may close these issues.

ICorDebugThread2.InterceptCurrentException corrupts process in x64 Windows


2 participants

@janvorli@jkotas