Sometimes, I have the situation that Windows waits at boot time for the kernel debugger to be attached. You see the text "Windows starting" but not the logo yet.
If I attach the debugger now, Windows 7's logo animation is played. Aftwards the logo starts to pulse. At this stage the boot process does not advance anymore. CPU usage drops to a minimum.
I wait usually several minutes, but nothing happens.
This does not happen all the time. However, if it happens, a VM reset won't help. I need to use startup repair to fix this problem. Unfortunately, it takes forever.
Any ideas what I can do except running startup repair ?
Thanks in advance !
To fix the problem you encountered, you just need to press F10 during boot up. And remove /debug and related parameters. Then press enter.
Suggestion:
Do not use /debug parameter for your default boot menu option. Copy your boot configuration to a new entry. Then set it to debug mode.
Windows don't know when you will use the debugger. So it has to wait.
Thanks.
I could solve the issue by leaving the mouse) inside the VM during bootup... Don't know why, but it solves the problem for me.
I'm debugging Win Embedded POSReady 7 SP1 x86 within VMware Workstation v9.0.2 on a Win7 Enterprise x64 host.
Related
I'm trying to run a legacy VB6 application on Windows 10. I'm using creating an .sdb shim file which detects the application's .exe using the Compatibility Administrator tool found in the Windows ADK. Whenever the .exe runs, the screen resolution is resized to a specific resolution. When the .exe stops, the resolution returns to normal.
The Compatibility fixes I'm using are "ForceDisplayMode" with parameters to display at the legacy app's old resolution. And also "ForceTemporaryModeChange" which will revert the screen resolution back to normal.
One problem I'm having is that when the application is open, if I close my laptop lid and reopen it, the .sdb stops working (windows doesn't log out). If I log out, the old resolution is maintained as expected. I'm trying to figure out if there's an option to maintain the .sdb's resolution, or if this is an oversight on Microsoft's end?
Ok, in the off chance that anyone has this incredibly obscure problem in the future, the solution was apparently to disable tablet mode on Windows 10 1809. That solves the .sdb shim being undone by closing the lid on my SP3/SP6s.
Edit: Ok, turns out that was not the solution. It was just coincidence, so I've uncheckmarked this answer. We had an image that didn't have this problem but then later images reverted this behavior. Still don't know why this occurs.
Edit 2: I still don't know why this occurs but I have a few observations that may help someone. I'm on Windows 10 LTSC Version 1809 Build 17763.615. It seems to have to do with specifically putting the SP6 to sleep via flipping up the keyboard. If you sleep by Windows > Power > Sleep or pressing the power button or letting the SP6 go to sleep on its own, the SDB is correctly maintained. Another odd observation is that if you sleep via the 3 ways listed above but then flip up the keyboard, the SDB is cancelled.
Recently my Visual Studio started to experience a delay before the program Starts Without Debugging.
This happens only when the following are met:
Console application
Start Without Debugging
There has been any change in the editor window from the last time program run.
After pressing Ctrl+F5 console application window opens and the cursor is active, but the execution is delayed.
The delay seems to be consistent in length (7-10 seconds), and not depend on the size of the code. I have checked two different installations of VS (2013 and 2015) on the same computer and the problem persists.
I have also checked that this delay occurs even for an empty Main().
There is a possibility that I have enabled some kind of an option/function in VS that causes this very specific delay, but I am not sure when this issue started occurring so I cannot trace back the change.
What could be the reason for this delay?
I will be grateful for help in this matter.
I made many attempts to diagnose the issue of the delay and one of the times that I pressed ctrl + F5 I have spotted a window opening in the background.
(It was definitely not visible everytime i tried to run without debugging).
It turns out that a functionality of Avira anti-virus had been scanning the code before it run for the first time. That is why when I made no changes to the code there was no delay.
Avira "Protection Cloud" is the name of the functionality responsible for the delays.
Link to Avira page about it and how to disable it: https://www.avira.com/en/support-for-home-knowledgebase-detail/kbid/1514
Sometimes if I have multiple editting windows open, this slows starting and stopping the debugger. Close all but those you are interested in and try again.
I have a Windows 10 64-bit PC (fresh install, not an upgrade).
When I run the setup file (web or offline alike) in order to install Visual Studio (2013 or 2015, Community edition), all I get is a small black rectangle on the screen (which I later found out that this is actually the title of the setup popup window), without the actual window of the installation.
I have tried it also after a reboot, and with various "versions" of the installation files (web, iso, standalone), but it's always the same situation.
What can I do about it? VS is my main development tool and I really need it on this computer as soon as possible.
Similar problem here. Program install ok but display blank screen after launched.
Problem solved when I changed my Nvidia graphics's global 3D setting to integrated graphics.
Right click desktop
Select Nvidia Control Panel
Select Manage 3D Settings
Under preferred graphics processor, select integrated graphics.
Apply.
If you are using a laptop with an external monitor, try unplugging it and using your primary monitor to launch. This worked for me. Laptops often have dual graphics cards and I believe we're hitting some issue with the way the Installer for VS was written (likely WPF)
Once I launced it and started the installation, I could safely plug my monitor in and it kept working properly.
I'm using an AMD GPU, It was a blank white screen but when I hover the mouse over it, I can see the text events
By the way
I went to my AMD Radeon Settings and saw that vs_installershell.exe and vs_setup_bootstrapper.exe were added automatically to the Switchable Graphics list
they were with Not Assigned Option which usually is like High Performace Option
means It would run it with my ATI GPU.
So I clicked on them
Selected Power Saving Option (to work with my Intel GPU)
Which worked and I can see the window of visual studio installer back
after restarting visual studio installer for sure.
whether is your graphics card, just turn on power saving for it.
Had the same issue. Since this topic is not accept any answare, there is one from https://developercommunity.visualstudio.com/content/problem/150888/visual-studio-installer-shows-blank-screen.html
Try to open installer as Admin.
You will probably have blank screen. Do not close it!
Open installer once more.
Hope it help other people with same issue.
the same thing happened to me, i didn't do anything i just waited for it and it started showing it's status, i suggest you close other running programs to avoid conflicts and performance hindering, and try it again.
This seems like a very shoddy issue. I've run into this problem too, and I tested all solutions that I came across online. These all work:
Running the installer as administrator, which is a blank screen. Leave it open and run a second instance of the installer, which will not be blank (doesn't need to be run as administrator the second time.
Changing screen settings so that the laptop screen is not being used.
Downloading the AMD Settings application, and setting vs_installershell.exe to run on powersaving mode. Restart the installer after saving the settings.
Use a default graphics driver instead of the AMD one.
I had the the same problem in my laptop. The temporary solution is: start the installer only without the battery, if installer starts you can connect the cable, it works fine.
I had to run integrated graphics rather than my Nvdia. That solved it for me.
Remember to change it back when programming in OpenGL and DirectX otherwise you may get a list of messages staying that nothing works.
I had the the same problem in my laptop. The work around is, in device management, remove the amd graphics or start the installer only with battery.
I'm running Python 2.7 with ArcGIS Desktop 10.1 on Windows for Server (2 Xeon 2.13 Ghz processors).
Is it possible to suppress or automatically close the dialogue box from Windows that says "python.exe has stopped working" when python crashes? I have a continuously running, multiprocessing script that sometimes crashes for unknown reasons (working on that). When I click to close the crash report window, the script restarts and everything is okay. I want this to happen automatically until I can track down what is causing the crashes.
Thanks very much!
Doug
Procedure for disabling the Windows Debugger dialogue box found here:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb204634(v=vs.85).aspx
This prevents the debug dialogue box that requires the user to click [Debug] or [Cancel] if python crashes.
However, there is now another Windows dialogue box that says "python.exe has stopped working. Please close the program" with a button [Close Program]. Sheesh!
The dialog you refer to is part of Windows Error Reporting.
The exact method varies between editions of Windows (Windows 7 instructions here, Google will happily provide for other versions...), but if you disable this feature of Windows, your crashes will happen a lot faster(!).
This is an simply an arcpy bug. You can try to avoid using the steps that are causing the crash, but it generally happens under different tools when used to process through a long list of data.
The only workaround I have found is to make my script save its progress along the way to disk so if you restart the process, it knows where to pickup from.
If you then disable windows debugger message by altering the registry (see below), you can then just repeatedly execute the script in cmd.exe until it completes the entire batch without having to close the process manually every time in between.
I know this is an awful workaround, but it is quite uncommon to have a python library kill off the python interpreter.
DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI = "1"
DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\Disabled = "1"
We have a counting meter hooked up to the serial port of a PC running Windows XP Embedded and everytime Windows starts, the meter starts clicking away about 90 times. We have tried using /fastdetect in boot.ini and it didn't work, even though it did work on XP Pro. We tried adding SkipEnumeration to the Device Parameter in the registry and it didn't work. When Plug&Play is disabled it won't click, but this isn't an option for us. Any other ideas? Thanks.
for anyone interested having this problem... I edited the Plug&Play registry and added a DependOnService multi-string with "Spooler" service as the data... this makes Plug&Play start later and allows enough time so that the meter isn't clicking crazy