When your program asserts, JIT pops up and asks you if you wish to close or debug the program.
After choosing debug, you need to confirm yes, debug.
Then, you need to choose a visual studio from the list, which is most likely the current running instance.
How do you automate this procedure?
I used AutoHotKey:
; Auto-click jit debug pop-up. Run the script as admin.
Loop,
{
WinWait, Visual Studio Just-In-Time Debugger
IfWinExist, Visual Studio Just-In-Time Debugger
{
;MsgBox, here
WinActivate, Visual Studio Just-In-Time Debugger
; click the yes button
SetControlDelay -1
ControlClick, Button1
; choose instance from the list
WinWait, Choose Just-In-Time Debugger
WinActivate, Choose Just-In-Time Debugger
;ControlGet, lb1, Hwnd, , ListBox1
;msgbox, %lb1%
ControlGet, items, List, , ListBox1
Loop, Parse, items, `n
{
;MsgBox, Item number %A_Index% is %A_LoopField%.
IfInString, A_LoopField, administrator
{
;MsgBox, found
Control, ChooseString, %A_LoopField%, ListBox1
break
}
}
}
}
In the listbox, I'm looking for an item that contains the substring 'administrator', but you can change that.
Related
On Windows 10, you can press Win+Tab to get a "Task View" view of all your windows. I'm trying to check if this is active at any given time. I have tried using a Low Level Keyboard Hook with WH_KEYBOARD_LL but this only allows me to detect the keypress, not if the switcher is active. I've looked at the Windows DWM API and haven't found anything else either.
I have also tried using EnumWindows() and EnumChildWindows(GetDesktopWindow(), ...) and did not find any difference in the output between having the task view shown and hidden.
Is there any accurate method to detect if this is being shown?
Here's a solution that works very consistently with my version of Windows (1709 build 16299.125) and doesn't require the processor-heavy approach of a call to EnumChildWindows:
bool isTaskView() {
//Get foreground window's name
HWND fgWindow = GetForegroundWindow();
TCHAR windowName[MAX_PATH] = L"";
GetWindowText(fgWindow, windowName, MAX_PATH);
//Compare with magic string name of Task View's window
std::wstring nameStr(windowName);
return nameStr == L"Task View";
}
In my application I need to get a list of all windows.
var windows = Application.Current.Windows;
If I run my application in debug mode I see not only my forms in the list, but also instances of Microsoft.XamlDiagnostics.WpfTap.WpfVisualTreeService.Adorners.AdornerLayerWindow created by Visual Studio debugging tool for XAML.
What is the right way to filter list of windows to ignore windows created by debugging tool? I don't want to reference additional assembly and check if
window is AdornerLayerWindow
and I don't want to filter like
window.GetType().Name != "AdornerLayerWindow"
Any other ideas?
I just do the trick window.ActualWidth != 0. It works good for me.
Application.Current.Windows
.Cast<Window>()
.Where(w => w.ActualWidth != 0)
.ToList()
.ForEach(w => w.Close());
I am using Microsoft Visual Studio 2010 and I am writing my code in C/C++.
I have code which automatically starts my installation process. Installation process requires UAC in this case, so I use ShellExecuteEx() API function with runas verb:
hWindow = InstallCreateWindow(NULL);
execInfo.cbSize = sizeof(execInfo);
execInfo.lpVerb = _strdup("runas");
execInfo.hwnd = hWindow;
execInfo.lpFile = szPath;
execInfo.lpParameters = szParams;
execInfo.fMask = SEE_MASK_NOCLOSEPROCESS | SEE_MASK_FLAG_NO_UI;
Sleep(1000);
SetActiveWindow(hWindow);
if(ShellExecuteEx(&execInfo))
return execInfo.hProcess;
if(GetLastError() == ERROR_CANCELLED)
{
// user answered NO to UAC prompt
}
InstallCreateWindow() function creates information window and it also creates separate window message thread. Window is visible, topmost and it responds to messages. I have to create it because I've read that correct hwnd parameter in SHELLEXECUTEINFO structure is required to keep UAC prompt window on top.
But this does not work. Sometimes UAC window runs maximized, but mainly it is minimized and highlighted in the taskbar. Is there a method to bring UAC window to top in any case?
JUST TO MARK IT AS ANSWERED
If the program that called ShellExecuteEx does not have foreground
activation, then the UAC dialog cannot take activation, so it has to
wait until the use activates it. Raymond Chen
This is Windows Forms application.
As in title, I can't debug Task in Visual Studio 2015. If I will check breakpoint at line var a = costam(); it will be hit, but if then I will press step into, or continue, execution will not be continued. This works fine in Console Application. For now i checked, that error appears when I'am trying to run my own method in Task, or if I'am invoking something.
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
Task.Run(() =>
{
var a = costam();
});
}
string costam()
{
return "s";
}
}
I would suggest changing the settings to break on any exception in the debug menu, not only uncaught ones. This option is called breaking when the exception is "thrown". Unfortunately the 2015 exceptions menu I'm not familiar with so I can't help you out with that.
There are certain exceptions that are caught and suppressed behind the scenes, especially with WinForms--constructors / load events are particularly shielded. It's likely that it doesn't like spawning a new thread in the UI thread which is why it's throwing an exception in your WinForms application but not the console application. This also explains why "stepping in" "doesn't work"--it steps in but the exception means the next breakpoint isn't hit.
Update 1 to VS2015 seems to solve this issue.
I have a PowerShell Script that I like to run with a Visual Interface (GUI - with Windows Form elements) Everything is working so far but I have one big problem:
Is it possible to display the command pane from PowerShell on the created Windows Form?
For Example: In one part of my PowerShell Script I am running the following command:
Upgrade-SPContentDatabase DBName
This command requires to confirm some messages with "Yes/No" that will be normally displayed in the command pane from PowerShell... Can this be done over the Windows Form so that I can hide the PowerShell-Script Window in the background?
Or is there any other way to display it in a new window that comes up?
Screenshot:
Any Ideas?
A messagebox (GUI) is different from a prompt. As long as you run a script in powershell console(not ISE), prompts will show up in the console. (There may be a setting to make them GUI like in ISE). A workaround would be to try and disable the confirm-prompts in the script, and create a messagebox yourself.
Try the following in your button's click-handler:
$handler_button1_Click=
{
$n = [System.Windows.Forms.MessageBox]::Show("Are you sure?", "Confirm", [System.Windows.Forms.MessageBoxButtons]::YesNo)
if ($n -eq "Yes") {
#Ignore confirm dialogs with -Confirm:$false
Upgrade-SPContentDatabase DBName -Confirm:$false
}
}