• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Windows Service Timed Action

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    #21
    Gods teeth what is all this bollox?

    I pray no one here has any investments at the suity bank of incompetence...

    Comment


      #22
      Originally posted by suityou01 View Post
      So in DoD() the commented out lines means the first instruction to log to the event log now fires. Comment them back in and it doesn't fire.
      and if you do them one by one?

      Comment


        #23
        My next task. PC has a 240v shortage. Reported. Stay tuned folks.


        Sent from my iMinion using Tapatalk
        Knock first as I might be balancing my chakras.

        Comment


          #24
          Originally posted by suityou01 View Post
          What is weird is how the code seems to look ahead before it fails.
          You've accidentally invented a time-machine!

          Of course, Threaded has already done that in the year 2352.

          Comment


            #25
            The thot plickens.

            OK so in DoD() I started commenting in the lines one by one until lo, it still worked.

            So I added some EventLog lines between each of the steps. Nothing fancy, "1", "2" etc.

            So this is what happened

            Code:
            LogEvent("About to do D()"); // This happened
            DoD();
            LogEvent("Done D()"); // This happened
            
            
            DoD()
            {
            Log Event("Doing D()"); This also happened
            
            DoD1SubTask();// This happened
            LogEvent("1"); //This did not happen
            
            DoD2SubTask();// This happened
            LogEvent("2"); //This did not happen
            
            LogEvent("Finished Doing D"); //This happened
            }
            Just found out that Windbg is installed on the server

            Off to track this sucker down.
            Knock first as I might be balancing my chakras.

            Comment


              #26
              Originally posted by suityou01 View Post
              The thot plickens.

              OK so in DoD() I started commenting in the lines one by one until lo, it still worked.

              So I added some EventLog lines between each of the steps. Nothing fancy, "1", "2" etc.

              So this is what happened

              Code:
              LogEvent("About to do D()"); // This happened
              DoD();
              LogEvent("Done D()"); // This happened
              
              
              DoD()
              {
              Log Event("Doing D()"); This also happened
              
              DoD1SubTask();// This happened
              LogEvent("1"); //This did not happen
              
              DoD2SubTask();// This happened
              LogEvent("2"); //This did not happen
              
              LogEvent("Finished Doing D"); //This happened
              }
              Just found out that Windbg is installed on the server

              Off to track this sucker down.
              FFS!

              Comment


                #27
                What's LogEvent using / doing?

                I thought you were a BA these days?

                Comment


                  #28
                  This must be the world's most complex windows service ever invented.
                  Vote Corbyn ! Save this country !

                  Comment


                    #29
                    Originally posted by mudskipper View Post
                    What's LogEvent using / doing?

                    I thought you were a BA these days?
                    I took a coding role to get some banking experience. Currently loving being back on the tools.

                    Originally posted by fullyautomatix View Post
                    This must be the world's most complex windows service ever invented.
                    Ha! Well no. It's actually very simple.
                    I was able to see the problem in windbg, but not clearly enough as I'm having some problems debugging managed code with it.

                    I am using the windbg, using SOS.dll and sosex.dll to set a breakpoint in my timer tick event.

                    The first hurdle is the windbg is built for debugging native code, so as my tick event is yet to fire at point of attaching the debugger, the event is waiting to be "jitted". Sosex.dll and adding a managed breakpoint gets neatly around this, but I am having some teething troubles with the pdb files. Checksum related I think. Leaving that little teaser for the morning.

                    What I noticed is that the DoD() thread, and associated lower down heavy lifting is instantiating the .net web service related classes at the very moment DoD() is pushed onto the call stack. This is giving the "look ahead" impression, as DoD() carries on executing as it appears to do this asynchronously. One of the .net classes goes pop which raises a first chance exception that then bubbles all the way up the stack and rips my thread down silently. This in effective creates a kind of race condition in my managed code, meaning it gets to varying points in it's execution depending when the .net web classes cause the tear down.

                    As I said, this doesn't happen when run outside svchost.

                    Very interesting problem, which when I crack my checksum problem I will be able to crack.
                    Knock first as I might be balancing my chakras.

                    Comment


                      #30
                      fixed it yet?

                      I can't help thinking you're overlooking something simpler than some kind of coding error. (not that I'd be surprised if it was a coding error of course )
                      When you say that the shell app and service run in the same security context, what context is that?
                      Have you promoted this to full admin?
                      Have you added all of the user rights assignments in the local security policy?
                      Have you turned on simple things like full OS event log, object access events, etc?
                      Is all of the processing local, or is the service trying to connect to resources over the network?

                      Comment

                      Working...
                      X