I have a .NET windows service that is calling cdb.exe to analyze crash dumps. I want to download the symbols from http://msdl.microsoft.com automatically when needed, using the argument:
-y srv*c:\symbols*http://msdl.microsoft.com/download/symbols
If I run the application as a console application, It works as expected and it downloads the needed symbols for each dump.
The problem is when I start the app as a windows service, the symbols are not downloaded and, if I turn symnoisy on, at cdb's output log I have an entry for each symbol saying that the symbol hasn't been found at http://msdl.microsoft.com
So, I've checked it using a sniffer and the funny thing is that no request is made to the microsoft symbols server when running as a service.
Googling a little, I've found that I'm not the only one with this issue and it seems that the problem is that when running an application as a windows service, it is using winHTTP library for http requests, instead of wininet, which I think is the root of the problem: http://support.microsoft.com/kb/238425
So, I don't know why, cdb is not able to connect to ms symbols server using winHTTP library and I need a way to force cdb use wininet by default.
Anyone has an idea of a workaround to this issue?
Full answer here: https://web.archive.org/web/20150221111112/http://infopurge.tumblr.com/post/10438913681/how-does-cdb-access-the-microsoft-symbol-server
When running from a Command Prompt, cdb uses WinINet to access internet resources. When running from a Windows service, cdb uses WinHTTP to access internet resources.
For WinHTTP you need to set some registry settings to stop an attempt to use a proxy (bogusproxy) for accessing the symbol server.
You can force cdb to use WinHttp from a command line, and thus emulate what is happening within the service for test purposes by typing the following before loading cdb.
SET DBGHELP_WINHTTP=AnythingOtherThanEmpty
To disable the WinHTTP proxy for cdb and symsrv you need to set the one of the following keys in the registry.
For x32 version of cdb running on a x32 bit machine from the Windows Service environment.
HKLM\Software\Microsoft\Symbol Server\NoInternetProxy DWORD 1.
For x32 version of cdb running on a x32 bit machine from a Command Prompt.
HKEY_CURRENT_USER\Software\Microsoft\Symbol Server\NoInternetProxy DWORD 1.
For x32 version of cdb running on a x64 bit machine from the Windows Service environment.
HKLM\Software\Wow6432Node\Microsoft\Symbol Server\NoInternetProxy DWORD 1.
For x32 version of cdb running on a x64 bit machine from a Command Prompt.
HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Symbol Server\NoInternetProxy DWORD 1.
For x64 version of cdb running on a x64 bit machine from the Windows Service environment.
HKLM\Software\Microsoft\Symbol Server\NoInternetProxy DWORD 1.
For x64 version of cdb running on a x64 bit machine from a Command Prompt.
HKEY_CURRENT_USER\Software\Microsoft\Symbol Server\NoInternetProxy DWORD 1.
You can also do the opposite - force dbghelp.dll to use WinInet instead of WinHTTP by adding
DBGHELP_WININET=1
to the system environment. It will fix the issue in cdb.exe and other tools that use dbghelp.dll, symchk.exe for example.
The same issue arises when running from the Task Scheduler.
I've tried using different accounts, to no avail, until I found this post.
I'm launching CDB from a python script (that performs all the 'magic' in getting the right prerequisites in place) and to ease the launch of python I've created a small batch script.
Adding the environment variable as described by sekogan solved the issue.
#echo off
setlocal
REM Forcing CDB to use WinInet instead of WinHTTP when running as a
REM 'service' due to that WinHTTP uses some bogus proxy when not run from
REM the console.
set DBGHELP_WININET=1
set PYTHONPATH=<your path>
call <path to venv>\Scripts\python.exe -m <script module> <params>
endlocal
Related
My Python project is very windows-centric, we want the benefits of containers but we can't give up Windows just yet.
I'd like to be able to use the Dockerized remote python interpreter feature that comes with IntelliJ. This works flawlessly with Python running on a standard Linux container, but appears to work not at all for Python running on a Windows container.
I've built a new image based on a standard Microsoft Server core image. I've installed Miniconda, bootstrapped a Python environment and verified that I can start an interactive Python session from the command prompt.
Whenever I try to set this up I get an error message: "Can't retrieve image ID from build stream". This occurs at the moment when IntelliJ would have normally detected the python interpreter and it's installed libraries.
I also tried giving the full path for the interpreter: c:\miniconda\envs\htp\python.exe
I've never seen any mention that this works in the documentation, but nor have I seen any mention that it does not work. I totally accept that Windows Containers are an oddity, so it's entirely possible that IntelliJ's remote-Python feature was never tested on Python running in Windows containers.
So, has anybody got this feature working with Python running on a Windows container yet? Is there any reason to believe that it does or does not work?
Regrettably, it is not supported yet. Please vote for the feature request https://youtrack.jetbrains.com/issue/PY-45222 in order to increase its priority.
this is my first post I am having some trouble with an app, in Visual Studio I can run it on Debug without any issue and everything works correctly, but when I deploy it using IIS I can access any page except of the ones where there is an interaction with an access database. If I search through virtual directory I can download the file without an issue.
Do you have any recommendation?
Are you running x32 or x64 iis? (Usually it x64).
Of course on your desktop, then Visual Studio defaults to x32, and that would explain why the Access database engine (ACE) works. You likely should force your project to x32 or x64 (and then ensure that you have a x64 bit version of the ACE (Access) istalled on your developer machie. You then want to ensure that you launching the x64 bit version of IIS.
You don’t need Access installed on your server, but you will need the ACE database engine – and the most easy way to ensure that data engine is installed is simply installing the Access runtime on that server.
Give that the standard ACE database engine download is x32, then I would look into this issue. You could (should) be able to resolve the issue by installing a x64 bit Access runtime on that server – this would also suggest a possible update to your connection strings. And I would check/test the connection string you are using once you resolve the x64 bit version of Access. The path name in your connection string will ALWAYS be a absolute path (not a relative one).
I'm getting hard time finding, what security is in place inside Docker NanoServer Container - when I execute .exe file (for example .net x32 or x64 unsigned application or some other installer) inside - I get absolutely no error or execution flow message.
When I execute signed applications For example Systinternals Nano suite, all of applications from the package can be executed without any issues.
Is there a way for more verbose output or some system logs inside Nanoserver for better diagnosis of this issue ?
My Docker NanoServer Container version:
BuildNumber: 14393
Version: 10.0.14393
64-bit
As mentioned on this answer, Nano server is support only .Net Core, and not full .Net framework.
Also, MS declined request to support full .Net versions in the Nano Server.
I need to work with Delphi 6 Update 2 in Windows 8.1 x64 (in case you were wondering, it's about maintaining an old application, migrating to a newer version is not an option. I can't use a VM because I use the same machine to connect to some peripherals that don't work in a VM).
The problem is that Update 2 has a 32 bit installer with a 16 bit stub. So the current behaviour is that the installer starts, it extracts the files in a temp location, starts the setup then nothing appears on screen.
So far, I gathered that it is impossible to do it. But the same behaviour I 've seen for SQL Server 2000 (don't ask) but there I was able to use msetup.exe (DemoShield) to open a sqlservr.dbd that started the script. However, there is no such dbd file. I guess I was lucky on SQLServer 2000.
So far I've tried compatibility mode, DosBox, replacing the setup file with both Installshield 3 and 5, waiting for hours for the setup to start (sometimes, W8 does that), even comparing files and registries on an XP machine before and after update 2 but this might be a bit too risky to apply on a real machine.
Since Windows 8.1 86 includes Hyper-V for running VMs, most modern hardware supports Hyper-V, and Windows 8 x86 can still run 16-bit based apps:
Install a Windows 8.1 x86 VM under your host physical machine, then install it there.
The up-tick: it is easy to move your VM to a new host without needing to reinstall a full new VM.
See http://www.techrepublic.com/blog/windows-and-office/get-started-with-windows-8-client-hyper-v-the-right-way/7893/ and http://www.infoworld.com/d/virtualization/5-excellent-uses-of-windows-8-hyper-v-208436 to get started with Hyper-V.
Hyper-V can redirect quite a bit of hardware from the host to the VM nowadays. For "old" hardware like COM and LPT ports you often can buy USB adapters that can be redirected.
If installing on x86 Windows 8.1 works and x64 fails, I think you have proved the assumption that the 16-bit portion of the installer is the culprit.
Maybe my blog post from last year can solve your problem:
http://blog.dummzeuch.de/2013/11/11/delphi-6-on-windows-8-1/
excerpt:
I just deleted the registry entry
HKCU\Software\Borland\Delphi\6.0\LM
(I did not make a backup, what would have been the point?)
I started Delphi 6, ignored the warning about incompatibilities (which was talking about Delphi 7 anyway) and went through the registration/activation process again. This time it worked.
Maybe I should mention, that I did not install any of my Delphi versions to c:\program files but put them into c:\Delphi instead to avoid any problems with access rights to the installation directory.
I have Windows Server 2008 R2 Machine that is running a Delphi 2007 application. Update: Switching Delphi versions is currently not an option. I have Delphi XE but there are over 300,000 lines of code to review before any switch can occur.
I have run into a problem where I would like to step through the code. I don't want to install Delphi on the machine, so I have installed the remote debugger.
Updated steps to be more complete:
Compile app with Remote Debug Symbols
Copy Application and Remote Debug Symbols to Remote Location.
Launched an Command Prompt (Running As an Administrator) on the Remote Machine.
Enabled Server Firewall exception for rmtdbg105 process.
Run rmtdbg105 -listen in the Command Prompt
I run the process I want to debug.
On my local machine I select attach to process and select the remote process.
Press Attach
Behavior observed:
Remote Process locks up and stops running, and so does Delphi on my machine.
I have waited several minutes just in case it caused by some type of network performance problem.
Is there step I am missing? I am looking for a way to get this to work.
Move back to Delphi 7, or up to Delphi XE, and try again. [Moving up to XE might be a bit of work, because you need to port your sources up to unicode delphi language level.]
I never did get Delphi 2007 remote debug to work reliably. The freeze-ups you see are something I remember too, when I was using Delphi 2007. I found that it froze less often when the PC had been rebooted recently. After a reboot you might get a few more uses, before you need to reboot again.
Did you run the remote debugger from a privileged console? Also check the debugger files against those in Delphi bin directory, IIRC some files has been updated by a patch, but the remote debugger installer wasn't. Try to use the updated files as well.
Anyway the 2007 debugger has issue under 7 and I guess it may have as well under 2008 R2, there is an unsupported patch from Embarcadero site, try that too.