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
Related
I've got a VB.Net Windows Form application containing several controls (labels, groupboxes, comboboxes, etc.) This application is deployed to several PCs running Windows 10. There are also Win10 tablets connecting to these PCs via Remote Desktop. The issue is that the text on the form sometimes gets resized and overlaps onto other controls when viewed on the tablet. In other words, the text becomes too big.
I thought this was only happening when using Remote Desktop but today I saw it happen on a PC too. This is the first time this has happened. One difference is that the PC was re-imaged in the field instead of being brought back to the office first. The monitors used between the two locations are different, and I'm suspecting this has something to do with it. I know there are DPI and resolution factors to consider but don't fully understand how to rectify them in this case, or if they're even applicable.
Here's how it looks as designed and running on my dev PC:
And here's how it looks when running on the production PC (sorry for the grainy image):
Of note is that some text doesn't appear to get oversized, for example the "Currently: 6 ft/min". All fonts are Microsoft Sans Serif.
Suggestions?
The answer provided here worked for me by changing the compatibility settings for the executable. Another method is provided here but I haven't had a chance to test it yet.
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.
I have been trying to get windows 8.1 to force into a blue screen, but all of my attempts have failed. I don't really want to go into driver code or anything to do it, but just crash it using some sort of silly loop hole.
I tried creating the CrashOnCtrlScroll registry and it doesn't seem to work, even after restarting my computer. I also tried ending csrss, but microsoft has decided to let the user have no control and denies access at all costs (even after an informative prompt window).
I looked online for a while, but can't find anything on blue screening 8.1. It seems that everything out there is for 8 and below.
Notmyfault , a portable tool created by Microsoft's Mark Russinovich for the Windows Internals book will help you get a BSOD with more than a couple of ways (i.e High IRQ fault, hang IRP, stack trash, deadlock, etc)
Which registry key have you tried? There is different key location for PS2 and USB Keyboard.
USB Registry Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid
Add DWORD32, name= CrashOnCtrlScroll, value =0x1
PS2 Registry Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt
Add DWORD32, name= CrashOnCtrlScroll, value =0x1
Restart. Hold the RIGHT CTRL key and press SCROLL LOCK twice quicky.
I'm doing some driver development on my Windows machine and I've been wondering why pressing the PrtSc (print screen) button to take a screen capture seems to hang my machine. There are some forums that suggest this happens when the DEBUG boot option is set in Windows and that this is a panic/bug-check in the Windows kernel.
Is this a Windows bug? Or is this actually useful in some way, like in Linux where PrtSc/SysRq is actually a kernel interrupt key?
UPDATE #1: I'm using Windows 7 x64 Professional Build 7601.
https://msdn.microsoft.com/en-us/library/windows/hardware/ff541727(v=vs.85).aspx
You can disable the SYSRQ key by editing the registry. In the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\i8042prt\Parameters registry key, create a value named BreakOnSysRq and set it equal to DWORD 0x0. Then, restart the computer. After you have restarted the computer, you can press the SYSRQ key on the target computer's keyboard and it will not break into the kernel debugger.
Obviously, you're likely using a usb keyboard, so make sure to add the BreakOnSysRq = 0 value data pair to kbdhid\Parameters (and for good measure hidusb and kbdclass, not i8042prt. This will prevent the PrntScr key from being interpreted as SysRq.
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.