I've setup a remote debugging configuration in PyCharm based on this link. Despite the fact that I unmarked the Suspend after connect option, the debugger suspends upon connect and I must manually resume the program on each run.
Is there a way for the remote debugger not to suspend on connect?
You could try passing suspend=False to pydevd.settrace() in case PyCharm has some problem with applying this setting itself.
Related
Because of the possibility of full system failure, I am using VM's as the environment for debugging a system startup component like "userinit", which executes before the desktop appears. How do I configure the VM's remote debugger and system so I can debug from the first line of code?
Look here:
Setting Up Kernel-Mode Debugging Manually
I am able to run my web application on the remote machine (after logging into VM using VPN) without debug but when I try to attach the process I don't find application process to attach for debugging even after I checking the option of show processes from all users.
If I try to start application with debug dotnet.exe crashes immediately, I believe this problem is due to VPN which is blocking the process but not sure how to fix it.
I'm wanting to start developing with NaCl / Pepper and I've gotten my build environment working great, but I can't seem to use any of the examples in my browser.
I've enabled Native Client, debugging, etc. But none of the modules seem to trigger the 'loaded' event, so I have no idea what is going on. This goes for .pexe and .nexe
I have the git here, and I honestly have no idea if there's a problem with my build process, my browser configuration, or what. Has anybody got a clue what's going on here?
This is the closest I've gotten to an error message, and apparently this is a chrome runtime flag, but running chrome with this flag has no effect, and now instead of working, no messages are output.
Try disabling debugging. Enabling debugging means that the NaCl loader will start the Native Client module, and then immediately suspend it and wait for the debugger to connect (then you can resume it with the debugger). So if you don't connect a debugger it will just wait forever. Also if you want to use the debugger on Windows, you need to disable Chrome's sandbox to allow the local TCP connection (for the record, the error message that gets cut off in the screen shot links to the following chrome bug)
I have a Windows service written in CPP that I start manually. The service starts up just fine and works ok. However we have recently noticed in the Windows Services GUI that the service shows in the Starting state. Upon examining the Event Viewer it clearly shows that the service has entered the Running state.
Anyone got any nuggets of gold on this one?
Thanks.
The problem turned out to be an unaccounted for call to the SCM to start the service. Deleted the line and the problem went away.
I have a service application that on startup and shutdown logs an event log record.
I rebuild the application frequently and also then the executable on the host machine. And here is the problem, after my service shutdown the Windows Eventlog service (not the event log viewer) is holding an open handle to the executable so I cant update it.
I have the event log messages embedded in the executable, i could move it out but then I just move the update problem to another file.
I've double checked and I have paired ::RegisterEventSource/::DeregisterEventSource correctly.
Anyone encountered this problem ?
I've also run into this issue, so just adding some of my experiences.
I have a Windows 2008 Service system (have not seen this on 2003 Server), and when I stop my service, and instance of svchost.exe loads the service executable (visible using vmmap.exe or Process Hacker) preventing it from being deleted/overwritten during uninstall/install. The instance of svchost.exe is running the DHCP Client (Dhcp), TCP/IP NetBIOS Helper (lmhosts), and Windows Event Log (EventLog) services.
In our case, we have created a registry entry to make our service executable an event source. (though I'm unsure exactly why we are doing this, or whether we should be doing this).
Empirically, if I remove that registry entry before stopping the service, the executable is not loaded by svchost.exe and all is fine. If the service has already been stopped and executable loaded by svchost.exe, restarting the Event Log service (or killing the process) also frees up the executable.
I'm guessing our service is not well-behaved (perhaps a side effect of being a 32-bit process on 64-bit OS?) or correctly installed, but haven't isolated the issue yet.
Update: It appears this issue is only happening on HP systems (and not Dell or IBM) which is curious. There are HP-specific management components installed, so perhaps one of them is altering the behavior somehow?
I've also run into this issue. In my case, nxlog service reading logs. Simply stop nxlog service before replace event source file.
I think it is probably the event log viewer. Close the viewer and you'll be fine.